commit 8e6e2188d949ddc4d8f613fd115ac7177f7e3b2b Author: Greg Kroah-Hartman Date: Sun Oct 19 16:23:23 2025 +0200 Linux 6.1.157 Link: https://lore.kernel.org/r/20251017145129.000176255@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Hardik Garg Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit b8291d6d98545d954f3d7fa46f5655e2b8a23973 Author: Jason Andryuk Date: Fri Oct 17 09:41:17 2025 -0400 xen/events: Update virq_to_irq on migration [ Upstream commit 3fcc8e146935415d69ffabb5df40ecf50e106131 ] VIRQs come in 3 flavors, per-VPU, per-domain, and global, and the VIRQs are tracked in per-cpu virq_to_irq arrays. Per-domain and global VIRQs must be bound on CPU 0, and bind_virq_to_irq() sets the per_cpu virq_to_irq at registration time Later, the interrupt can migrate, and info->cpu is updated. When calling __unbind_from_irq(), the per-cpu virq_to_irq is cleared for a different cpu. If bind_virq_to_irq() is called again with CPU 0, the stale irq is returned. There won't be any irq_info for the irq, so things break. Make xen_rebind_evtchn_to_cpu() update the per_cpu virq_to_irq mappings to keep them update to date with the current cpu. This ensures the correct virq_to_irq is cleared in __unbind_from_irq(). Fixes: e46cdb66c8fc ("xen: event channels") Cc: stable@vger.kernel.org Signed-off-by: Jason Andryuk Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20250828003604.8949-4-jason.andryuk@amd.com> [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db62b1e7b1d3f8e97b59f9f8e07829356d0ff3e4 Author: Jan Kara Date: Fri Sep 12 12:38:37 2025 +0200 writeback: Avoid excessively long inode switching times [ Upstream commit 9a6ebbdbd41235ea3bc0c4f39e2076599b8113cc ] With lazytime mount option enabled we can be switching many dirty inodes on cgroup exit to the parent cgroup. The numbers observed in practice when systemd slice of a large cron job exits can easily reach hundreds of thousands or millions. The logic in inode_do_switch_wbs() which sorts the inode into appropriate place in b_dirty list of the target wb however has linear complexity in the number of dirty inodes thus overall time complexity of switching all the inodes is quadratic leading to workers being pegged for hours consuming 100% of the CPU and switching inodes to the parent wb. Simple reproducer of the issue: FILES=10000 # Filesystem mounted with lazytime mount option MNT=/mnt/ echo "Creating files and switching timestamps" for (( j = 0; j < 50; j ++ )); do mkdir $MNT/dir$j for (( i = 0; i < $FILES; i++ )); do echo "foo" >$MNT/dir$j/file$i done touch -a -t 202501010000 $MNT/dir$j/file* done wait echo "Syncing and flushing" sync echo 3 >/proc/sys/vm/drop_caches echo "Reading all files from a cgroup" mkdir /sys/fs/cgroup/unified/mycg1 || exit echo $$ >/sys/fs/cgroup/unified/mycg1/cgroup.procs || exit for (( j = 0; j < 50; j ++ )); do cat /mnt/dir$j/file* >/dev/null & done wait echo "Switching wbs" # Now rmdir the cgroup after the script exits We need to maintain b_dirty list ordering to keep writeback happy so instead of sorting inode into appropriate place just append it at the end of the list and clobber dirtied_time_when. This may result in inode writeback starting later after cgroup switch however cgroup switches are rare so it shouldn't matter much. Since the cgroup had write access to the inode, there are no practical concerns of the possible DoS issues. Acked-by: Tejun Heo Signed-off-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 68be7f61083768e88521492093139277c98ba87f Author: Jan Kara Date: Fri Sep 12 12:38:36 2025 +0200 writeback: Avoid softlockup when switching many inodes [ Upstream commit 66c14dccd810d42ec5c73bb8a9177489dfd62278 ] process_inode_switch_wbs_work() can be switching over 100 inodes to a different cgroup. Since switching an inode requires counting all dirty & under-writeback pages in the address space of each inode, this can take a significant amount of time. Add a possibility to reschedule after processing each inode to avoid softlockups. Acked-by: Tejun Heo Signed-off-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit cd572b903a21af8a5a05d7932acd337bc0f4ea03 Author: Tetsuo Handa Date: Sat Aug 30 19:01:01 2025 +0900 cramfs: Verify inode mode when loading from disk [ Upstream commit 7f9d34b0a7cb93d678ee7207f0634dbf79e47fe5 ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/429b3ef1-13de-4310-9a8e-c2dc9a36234a@I-love.SAKURA.ne.jp Acked-by: Nicolas Pitre Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 5895d78ee7fa67348a44718d71b0c4bc3ff459d5 Author: Lichen Liu Date: Fri Aug 15 20:14:59 2025 +0800 fs: Add 'initramfs_options' to set initramfs mount options [ Upstream commit 278033a225e13ec21900f0a92b8351658f5377f2 ] When CONFIG_TMPFS is enabled, the initial root filesystem is a tmpfs. By default, a tmpfs mount is limited to using 50% of the available RAM for its content. This can be problematic in memory-constrained environments, particularly during a kdump capture. In a kdump scenario, the capture kernel boots with a limited amount of memory specified by the 'crashkernel' parameter. If the initramfs is large, it may fail to unpack into the tmpfs rootfs due to insufficient space. This is because to get X MB of usable space in tmpfs, 2*X MB of memory must be available for the mount. This leads to an OOM failure during the early boot process, preventing a successful crash dump. This patch introduces a new kernel command-line parameter, initramfs_options, which allows passing specific mount options directly to the rootfs when it is first mounted. This gives users control over the rootfs behavior. For example, a user can now specify initramfs_options=size=75% to allow the tmpfs to use up to 75% of the available memory. This can significantly reduce the memory pressure for kdump. Consider a practical example: To unpack a 48MB initramfs, the tmpfs needs 48MB of usable space. With the default 50% limit, this requires a memory pool of 96MB to be available for the tmpfs mount. The total memory requirement is therefore approximately: 16MB (vmlinuz) + 48MB (loaded initramfs) + 48MB (unpacked kernel) + 96MB (for tmpfs) + 12MB (runtime overhead) ≈ 220MB. By using initramfs_options=size=75%, the memory pool required for the 48MB tmpfs is reduced to 48MB / 0.75 = 64MB. This reduces the total memory requirement by 32MB (96MB - 64MB), allowing the kdump to succeed with a smaller crashkernel size, such as 192MB. An alternative approach of reusing the existing rootflags parameter was considered. However, a new, dedicated initramfs_options parameter was chosen to avoid altering the current behavior of rootflags (which applies to the final root filesystem) and to prevent any potential regressions. Also add documentation for the new kernel parameter "initramfs_options" This approach is inspired by prior discussions and patches on the topic. Ref: https://www.lightofdawn.org/blog/?viewDetailed=00128 Ref: https://landley.net/notes-2015.html#01-01-2015 Ref: https://lkml.org/lkml/2021/6/29/783 Ref: https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs Signed-off-by: Lichen Liu Link: https://lore.kernel.org/20250815121459.3391223-1-lichliu@redhat.com Tested-by: Rob Landley Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e10c36a771c5cc910abd9fe4aa9033ee32a47c38 Author: gaoxiang17 Date: Sat Aug 2 10:21:23 2025 +0800 pid: Add a judgment for ns null in pid_nr_ns [ Upstream commit 006568ab4c5ca2309ceb36fa553e390b4aa9c0c7 ] __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Signed-off-by: gaoxiang17 Link: https://lore.kernel.org/20250802022123.3536934-1-gxxa03070307@gmail.com Reviewed-by: Baoquan He Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 8a294fbb3c355362b4362da47a22094ce01838a6 Author: Tetsuo Handa Date: Wed Aug 13 00:17:44 2025 +0900 minixfs: Verify inode mode when loading from disk [ Upstream commit 73861970938ad1323eb02bbbc87f6fbd1e5bacca ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/ec982681-84b8-4624-94fa-8af15b77cbd2@I-love.SAKURA.ne.jp Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 415d512e90273355cfbb4317507565483952dccf Author: Matthieu Baerts (NGI0) Date: Thu Sep 25 12:32:36 2025 +0200 mptcp: pm: in-kernel: usable client side with C-flag commit 4b1ff850e0c1aacc23e923ed22989b827b9808f9 upstream. When servers set the C-flag in their MP_CAPABLE to tell clients not to create subflows to the initial address and port, clients will likely not use their other endpoints. That's because the in-kernel path-manager uses the 'subflow' endpoints to create subflows only to the initial address and port. If the limits have not been modified to accept ADD_ADDR, the client doesn't try to establish new subflows. If the limits accept ADD_ADDR, the routing routes will be used to select the source IP. The C-flag is typically set when the server is operating behind a legacy Layer 4 load balancer, or using anycast IP address. Clients having their different 'subflow' endpoints setup, don't end up creating multiple subflows as expected, and causing some deployment issues. A special case is then added here: when servers set the C-flag in the MPC and directly sends an ADD_ADDR, this single ADD_ADDR is accepted. The 'subflows' endpoints will then be used with this new remote IP and port. This exception is only allowed when the ADD_ADDR is sent immediately after the 3WHS, and makes the client switching to the 'fully established' mode. After that, 'select_local_address()' will not be able to find any subflows, because 'id_avail_bitmap' will be filled in mptcp_pm_create_subflow_or_signal_addr(), when switching to 'fully established' mode. Fixes: df377be38725 ("mptcp: add deny_join_id0 in mptcp_options_received") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/536 Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250925-net-next-mptcp-c-flag-laminar-v1-1-ad126cc47c6b@kernel.org Signed-off-by: Jakub Kicinski [ Conflict in pm.c, because commit 498d7d8b75f1 ("mptcp: pm: remove '_nl' from mptcp_pm_nl_is_init_remote_addr") renamed an helper in the context, and it is not in this version. The same new code can be applied at the same place. Conflict in pm_kernel.c, because the modified code has been moved from pm_netlink.c to pm_kernel.c in commit 8617e85e04bd ("mptcp: pm: split in-kernel PM specific code"), which is not in this version. The resolution is easy: simply by applying the patch where 'pm_kernel.c' has been replaced 'pm_netlink.c'. Conflict in pm_netlink.c, because commit b83fbca1b4c9 ("mptcp: pm: reduce entries iterations on connect") is not in this version. Instead of using the 'locals' variable (struct mptcp_pm_local *) from the new version and embedding a "struct mptcp_addr_info", we can simply continue to use the 'addrs' variable (struct mptcp_addr_info *). Because commit b9d69db87fb7 ("mptcp: let the in-kernel PM use mixed IPv4 and IPv6 addresses") is not in this version, it is also required to pass an extra parameter to fill_local_addresses_vec(): struct mptcp_addr_info *remote, which is available from the caller side. Conflict in protocol.h, because commit af3dc0ad3167 ("mptcp: Remove unused declaration mptcp_sockopt_sync()") is not in this version and it removed one line in the context. The resolution is easy because the new function can still be added at the same place. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 93faabb55a377f577102dc37ed795a07aff201e2 Author: Varad Gautam Date: Thu Oct 16 07:57:09 2025 -0400 asm-generic/io.h: Skip trace helpers if rwmmio events are disabled [ Upstream commit 8327bd4fcb6c1dab01ce5c6ff00b42496836dcd2 ] With `CONFIG_TRACE_MMIO_ACCESS=y`, the `{read,write}{b,w,l,q}{_relaxed}()` mmio accessors unconditionally call `log_{post_}{read,write}_mmio()` helpers, which in turn call the ftrace ops for `rwmmio` trace events This adds a performance penalty per mmio accessor call, even when `rwmmio` events are disabled at runtime (~80% overhead on local measurement). Guard these with `tracepoint_enabled()`. Signed-off-by: Varad Gautam Fixes: 210031971cdd ("asm-generic/io: Add logging support for MMIO accessors") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0beb2357a7d9e4005d95b90994d832d6883cdbca Author: Vladimir Oltean Date: Thu Oct 16 07:57:08 2025 -0400 asm-generic/io.h: suppress endianness warnings for relaxed accessors [ Upstream commit 05d3855b4d21ef3c2df26be1cbba9d2c68915fcb ] Copy the forced type casts from the normal MMIO accessors to suppress the sparse warnings that point out __raw_readl() returns a native endian word (just like readl()). Signed-off-by: Vladimir Oltean Signed-off-by: Arnd Bergmann Stable-dep-of: 8327bd4fcb6c ("asm-generic/io.h: Skip trace helpers if rwmmio events are disabled") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 57edac22ab8026fbb2d614544fb130adca46c0ee Author: Sai Prakash Ranjan Date: Thu Oct 16 07:57:07 2025 -0400 asm-generic/io: Add _RET_IP_ to MMIO trace for more accurate debug info [ Upstream commit 5e5ff73c2e5863f93fc5fd78d178cd8f2af12464 ] Due to compiler optimizations like inlining, there are cases where MMIO traces using _THIS_IP_ for caller information might not be sufficient to provide accurate debug traces. 1) With optimizations (Seen with GCC): In this case, _THIS_IP_ works fine and prints the caller information since it will be inlined into the caller and we get the debug traces on who made the MMIO access, for ex: rwmmio_read: qcom_smmu_tlb_sync+0xe0/0x1b0 width=32 addr=0xffff8000087447f4 rwmmio_post_read: qcom_smmu_tlb_sync+0xe0/0x1b0 width=32 val=0x0 addr=0xffff8000087447f4 2) Without optimizations (Seen with Clang): _THIS_IP_ will not be sufficient in this case as it will print only the MMIO accessors itself which is of not much use since it is not inlined as below for example: rwmmio_read: readl+0x4/0x80 width=32 addr=0xffff8000087447f4 rwmmio_post_read: readl+0x48/0x80 width=32 val=0x4 addr=0xffff8000087447f4 So in order to handle this second case as well irrespective of the compiler optimizations, add _RET_IP_ to MMIO trace to make it provide more accurate debug information in all these scenarios. Before: rwmmio_read: readl+0x4/0x80 width=32 addr=0xffff8000087447f4 rwmmio_post_read: readl+0x48/0x80 width=32 val=0x4 addr=0xffff8000087447f4 After: rwmmio_read: qcom_smmu_tlb_sync+0xe0/0x1b0 -> readl+0x4/0x80 width=32 addr=0xffff8000087447f4 rwmmio_post_read: qcom_smmu_tlb_sync+0xe0/0x1b0 -> readl+0x4/0x80 width=32 val=0x0 addr=0xffff8000087447f4 Fixes: 210031971cdd ("asm-generic/io: Add logging support for MMIO accessors") Signed-off-by: Sai Prakash Ranjan Signed-off-by: Arnd Bergmann Stable-dep-of: 8327bd4fcb6c ("asm-generic/io.h: Skip trace helpers if rwmmio events are disabled") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f734944e12b2e0abe11b37deeea881febb81d383 Author: Lance Yang Date: Wed Sep 17 21:31:37 2025 +0800 selftests/mm: skip soft-dirty tests when CONFIG_MEM_SOFT_DIRTY is disabled commit 0389c305ef56cbadca4cbef44affc0ec3213ed30 upstream. The madv_populate and soft-dirty kselftests currently fail on systems where CONFIG_MEM_SOFT_DIRTY is disabled. Introduce a new helper softdirty_supported() into vm_util.c/h to ensure tests are properly skipped when the feature is not enabled. Link: https://lkml.kernel.org/r/20250917133137.62802-1-lance.yang@linux.dev Fixes: 9f3265db6ae8 ("selftests: vm: add test for Soft-Dirty PTE bit") Signed-off-by: Lance Yang Acked-by: David Hildenbrand Suggested-by: David Hildenbrand Cc: Lorenzo Stoakes Cc: Shuah Khan Cc: Gabriel Krisman Bertazi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f4ca54bb9733049d2ffd158923f44ab6d934a382 Author: Rafael J. Wysocki Date: Thu Oct 16 19:00:07 2025 -0400 ACPI: property: Do not pass NULL handles to acpi_attach_data() [ Upstream commit baf60d5cb8bc6b85511c5df5f0ad7620bb66d23c ] In certain circumstances, the ACPI handle of a data-only node may be NULL, in which case it does not make sense to attempt to attach that node to an ACPI namespace object, so update the code to avoid attempts to do so. This prevents confusing and unuseful error messages from being printed. Also document the fact that the ACPI handle of a data-only node may be NULL and when that happens in a code comment. In addition, make acpi_add_nondev_subnodes() print a diagnostic message for each data-only node with an unknown ACPI namespace scope. Fixes: 1d52f10917a7 ("ACPI: property: Tie data nodes to acpi handles") Cc: 6.0+ # 6.0+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Sakari Ailus Tested-by: Sakari Ailus Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit feb1d463d73441ae2d35e5ccde91cd9c8552d207 Author: Rafael J. Wysocki Date: Thu Oct 16 19:00:06 2025 -0400 ACPI: property: Add code comments explaining what is going on [ Upstream commit 737c3a09dcf69ba2814f3674947ccaec1861c985 ] In some places in the ACPI device properties handling code, it is unclear why the code is what it is. Some assumptions are not documented and some pieces of code are based on knowledge that is not mentioned anywhere. Add code comments explaining these things. Signed-off-by: Rafael J. Wysocki Reviewed-by: Sakari Ailus Tested-by: Sakari Ailus Stable-dep-of: baf60d5cb8bc ("ACPI: property: Do not pass NULL handles to acpi_attach_data()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9a15de2a3ae5839b7f4efc823c1c82914bf089bb Author: Rafael J. Wysocki Date: Thu Oct 16 19:00:05 2025 -0400 ACPI: property: Disregard references in data-only subnode lists [ Upstream commit d06118fe9b03426484980ed4c189a8c7b99fa631 ] Data-only subnode links following the ACPI data subnode GUID in a _DSD package are expected to point to named objects returning _DSD-equivalent packages. If a reference to such an object is used in the target field of any of those links, that object will be evaluated in place (as a named object) and its return data will be embedded in the outer _DSD package. For this reason, it is not expected to see a subnode link with the target field containing a local reference (that would mean pointing to a device or another object that cannot be evaluated in place and therefore cannot return a _DSD-equivalent package). Accordingly, simplify the code parsing data-only subnode links to simply print a message when it encounters a local reference in the target field of one of those links. Moreover, since acpi_nondev_subnode_data_ok() would only have one caller after the change above, fold it into that caller. Link: https://lore.kernel.org/linux-acpi/CAJZ5v0jVeSrDO6hrZhKgRZrH=FpGD4vNUjFD8hV9WwN9TLHjzQ@mail.gmail.com/ Signed-off-by: Rafael J. Wysocki Reviewed-by: Sakari Ailus Tested-by: Sakari Ailus Stable-dep-of: baf60d5cb8bc ("ACPI: property: Do not pass NULL handles to acpi_attach_data()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 75b52144bcda352aa6574bcf0888c9068060c10f Author: Guenter Roeck Date: Thu Oct 16 13:50:58 2025 -0500 ipmi: Fix handling of messages with provided receive message pointer commit e2c69490dda5d4c9f1bfbb2898989c8f3530e354 upstream Prior to commit b52da4054ee0 ("ipmi: Rework user message limit handling"), i_ipmi_request() used to increase the user reference counter if the receive message is provided by the caller of IPMI API functions. This is no longer the case. However, ipmi_free_recv_msg() is still called and decreases the reference counter. This results in the reference counter reaching zero, the user data pointer is released, and all kinds of interesting crashes are seen. Fix the problem by increasing user reference counter if the receive message has been provided by the caller. Fixes: b52da4054ee0 ("ipmi: Rework user message limit handling") Reported-by: Eric Dumazet Cc: Eric Dumazet Cc: Greg Thelen Signed-off-by: Guenter Roeck Message-ID: <20251006201857.3433837-1-linux@roeck-us.net> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit f63723ca7d7623f9dae1990973cd158671f03c56 Author: Corey Minyard Date: Thu Oct 16 13:50:57 2025 -0500 ipmi: Rework user message limit handling commit b52da4054ee0bf9ecb44996f2c83236ff50b3812 upstream This patch required quite a bit of work to backport due to a number of unrelated changes that do not make sense to backport. This has been run against my test suite and passes all tests. The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer. Reported-by: Gilles BULOZ Closes: https://lore.kernel.org/lkml/aLsw6G0GyqfpKs2S@mail.minyard.net/ Fixes: 8e76741c3d8b ("ipmi: Add a limit on the number of users that may use IPMI") Cc: # 4.19 Signed-off-by: Corey Minyard Tested-by: Gilles BULOZ Signed-off-by: Greg Kroah-Hartman commit 5ef5ee7999dc604d16019e4e2b95319ff5b17a00 Author: Thomas Gleixner Date: Thu Oct 16 07:59:18 2025 -0400 rseq: Protect event mask against membarrier IPI [ Upstream commit 6eb350a2233100a283f882c023e5ad426d0ed63b ] rseq_need_restart() reads and clears task::rseq_event_mask with preemption disabled to guard against the scheduler. But membarrier() uses an IPI and sets the PREEMPT bit in the event mask from the IPI, which leaves that RMW operation unprotected. Use guard(irq) if CONFIG_MEMBARRIER is enabled to fix that. Fixes: 2a36ab717e8f ("rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ") Signed-off-by: Thomas Gleixner Reviewed-by: Boqun Feng Reviewed-by: Mathieu Desnoyers Cc: stable@vger.kernel.org [ Applied changes to include/linux/sched.h instead of include/linux/rseq.h ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8dbcf37df393d93c5c9d3cbc1d0443e8f9b86db0 Author: Qu Wenruo Date: Wed Oct 15 11:23:57 2025 -0400 btrfs: fix the incorrect max_bytes value for find_lock_delalloc_range() [ Upstream commit 7b26da407420e5054e3f06c5d13271697add9423 ] [BUG] With my local branch to enable bs > ps support for btrfs, sometimes I hit the following ASSERT() inside submit_one_sector(): ASSERT(block_start != EXTENT_MAP_HOLE); Please note that it's not yet possible to hit this ASSERT() in the wild yet, as it requires btrfs bs > ps support, which is not even in the development branch. But on the other hand, there is also a very low chance to hit above ASSERT() with bs < ps cases, so this is an existing bug affect not only the incoming bs > ps support but also the existing bs < ps support. [CAUSE] Firstly that ASSERT() means we're trying to submit a dirty block but without a real extent map nor ordered extent map backing it. Furthermore with extra debugging, the folio triggering such ASSERT() is always larger than the fs block size in my bs > ps case. (8K block size, 4K page size) After some more debugging, the ASSERT() is trigger by the following sequence: extent_writepage() | We got a 32K folio (4 fs blocks) at file offset 0, and the fs block | size is 8K, page size is 4K. | And there is another 8K folio at file offset 32K, which is also | dirty. | So the filemap layout looks like the following: | | "||" is the filio boundary in the filemap. | "//| is the dirty range. | | 0 8K 16K 24K 32K 40K | |////////| |//////////////////////||////////| | |- writepage_delalloc() | |- find_lock_delalloc_range() for [0, 8K) | | Now range [0, 8K) is properly locked. | | | |- find_lock_delalloc_range() for [16K, 40K) | | |- btrfs_find_delalloc_range() returned range [16K, 40K) | | |- lock_delalloc_folios() locked folio 0 successfully | | | | | | The filemap range [32K, 40K) got dropped from filemap. | | | | | |- lock_delalloc_folios() failed with -EAGAIN on folio 32K | | | As the folio at 32K is dropped. | | | | | |- loops = 1; | | |- max_bytes = PAGE_SIZE; | | |- goto again; | | | This will re-do the lookup for dirty delalloc ranges. | | | | | |- btrfs_find_delalloc_range() called with @max_bytes == 4K | | | This is smaller than block size, so | | | btrfs_find_delalloc_range() is unable to return any range. | | \- return false; | | | \- Now only range [0, 8K) has an OE for it, but for dirty range | [16K, 32K) it's dirty without an OE. | This breaks the assumption that writepage_delalloc() will find | and lock all dirty ranges inside the folio. | |- extent_writepage_io() |- submit_one_sector() for [0, 8K) | Succeeded | |- submit_one_sector() for [16K, 24K) Triggering the ASSERT(), as there is no OE, and the original extent map is a hole. Please note that, this also exposed the same problem for bs < ps support. E.g. with 64K page size and 4K block size. If we failed to lock a folio, and falls back into the "loops = 1;" branch, we will re-do the search using 64K as max_bytes. Which may fail again to lock the next folio, and exit early without handling all dirty blocks inside the folio. [FIX] Instead of using the fixed size PAGE_SIZE as @max_bytes, use @sectorsize, so that we are ensured to find and lock any remaining blocks inside the folio. And since we're here, add an extra ASSERT() to before calling btrfs_find_delalloc_range() to make sure the @max_bytes is at least no smaller than a block to avoid false negative. Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo Signed-off-by: David Sterba [ adapted folio terminology and API calls to page-based equivalents ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a89a4b30a134e78a00db339f1232e8a3fcad42f5 Author: Hans de Goede Date: Mon Oct 13 19:07:44 2025 -0400 mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag [ Upstream commit 64e0d839c589f4f2ecd2e3e5bdb5cee6ba6bade9 ] Testing has shown that reading multiple registers at once (for 10-bit ADC values) does not work. Set the use_single_read regmap_config flag to make regmap split these for us. This should fix temperature opregion accesses done by drivers/acpi/pmic/intel_pmic_chtdc_ti.c and is also necessary for the upcoming drivers for the ADC and battery MFD cells. Fixes: 6bac0606fdba ("mfd: Add support for Cherry Trail Dollar Cove TI PMIC") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250804133240.312383-1-hansg@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2221d66d3285ae72a560b0b14e79150d1412af66 Author: Andy Shevchenko Date: Mon Oct 13 19:07:43 2025 -0400 mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for cache_type [ Upstream commit 9eb99c08508714906db078b5efbe075329a3fb06 ] REGCACHE_NONE is the default type of the cache when not provided. Drop unneeded explicit assignment to it. Note, it's defined to 0, and if ever be redefined, it will break literally a lot of the drivers, so it very unlikely to happen. Signed-off-by: Andy Shevchenko Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250129152823.1802273-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones Stable-dep-of: 64e0d839c589 ("mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c42c69e421137920af076c88a233e230b776e2d Author: Hans de Goede Date: Mon Oct 13 19:07:42 2025 -0400 mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config max_register value [ Upstream commit 70e997e0107e5ed85c1a3ef2adfccbe351c29d71 ] The max_register = 128 setting in the regmap config is not valid. The Intel Dollar Cove TI PMIC has an eeprom unlock register at address 0x88 and a number of EEPROM registers at 0xF?. Increase max_register to 0xff so that these registers can be accessed. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241208150028.325349-1-hdegoede@redhat.com Signed-off-by: Lee Jones Stable-dep-of: 64e0d839c589 ("mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6411f840a9b5c47c00ca8e004733de232553870d Author: Shin'ichiro Kawasaki Date: Tue Oct 14 12:14:06 2025 -0400 PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release [ Upstream commit 85afa9ea122dd9d4a2ead104a951d318975dcd25 ] The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data") Signed-off-by: Shin'ichiro Kawasaki [mani: trimmed the stack trace] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Damien Le Moal Reviewed-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250916025756.34807-1-shinichiro.kawasaki@wdc.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3477a98c1ab60ca85da205020fb095721a166a59 Author: Wang Jiang Date: Tue Oct 14 12:14:05 2025 -0400 PCI: endpoint: Remove surplus return statement from pci_epf_test_clean_dma_chan() [ Upstream commit 9b80bdb10aee04ce7289896e6bdad13e33972636 ] Remove a surplus return statement from the void function that has been added in the commit commit 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities"). Especially, as an empty return statements at the end of a void functions serve little purpose. This fixes the following checkpatch.pl script warning: WARNING: void function return statements are not generally useful #296: FILE: drivers/pci/endpoint/functions/pci-epf-test.c:296: + return; +} Link: https://lore.kernel.org/r/tencent_F250BEE2A65745A524E2EFE70CF615CA8F06@qq.com Signed-off-by: Wang Jiang [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Stable-dep-of: 85afa9ea122d ("PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21169f469e6bf8ca607161342113d80cc806f8c3 Author: Namjae Jeon Date: Tue Oct 14 11:25:39 2025 -0400 ksmbd: add max ip connections parameter [ Upstream commit d8b6dc9256762293048bf122fc11c4e612d0ef5d ] This parameter set the maximum number of connections per ip address. The default is 8. Cc: stable@vger.kernel.org Fixes: c0d41112f1a5 ("ksmbd: extend the connection limiting mechanism to support IPv6") Signed-off-by: Namjae Jeon Signed-off-by: Steve French [ adjust reserved room ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a6e89ada1ff6b70df73f579071ffa6ade8ae7f98 Author: Yuan Chen Date: Mon Oct 13 23:05:28 2025 -0400 tracing: Fix race condition in kprobe initialization causing NULL pointer dereference [ Upstream commit 9cf9aa7b0acfde7545c1a1d912576e9bab28dc6f ] There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec : ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 : ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: return 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read and write memory barriers to guarantee that if CPU1 sees that kprobe functionality is enabled, it must also see that perf_events has been assigned. Link: https://lore.kernel.org/all/20251001022025.44626-1-chenyuan_fl@163.com/ Fixes: 50d780560785 ("tracing/kprobes: Add probe handler dispatcher to support perf and ftrace concurrent use") Cc: stable@vger.kernel.org Signed-off-by: Yuan Chen Signed-off-by: Masami Hiramatsu (Google) [ Drop fprobe changes + context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8118f66124895829443d09c207e654adcb2f9321 Author: Phillip Lougher Date: Mon Oct 13 16:41:27 2025 -0400 Squashfs: reject negative file sizes in squashfs_read_inode() [ Upstream commit 9f1c14c1de1bdde395f6cc893efa4f80a2ae3b2b ] Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity] Link: https://lkml.kernel.org/r/20250926222305.110103-1-phillip@squashfs.org.uk Link: https://lkml.kernel.org/r/20250926215935.107233-1-phillip@squashfs.org.uk Fixes: 6545b246a2c8 ("Squashfs: inode operations") Signed-off-by: Phillip Lougher Reported-by: syzbot+f754e01116421e9754b9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68d580e5.a00a0220.303701.0019.GAE@google.com/ Cc: Amir Goldstein Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22c6d91aa34dbfac31eed2b60ad540bc516fa56d Author: Phillip Lougher Date: Mon Oct 13 16:41:26 2025 -0400 Squashfs: add additional inode sanity checking [ Upstream commit 9ee94bfbe930a1b39df53fa2d7b31141b780eb5a ] Patch series "Squashfs: performance improvement and a sanity check". This patchset adds an additional sanity check when reading regular file inodes, and adds support for SEEK_DATA/SEEK_HOLE lseek() whence values. This patch (of 2): Add an additional sanity check when reading regular file inodes. A regular file if the file size is an exact multiple of the filesystem block size cannot have a fragment. This is because by definition a fragment block stores tailends which are not a whole block in size. Link: https://lkml.kernel.org/r/20250923220652.568416-1-phillip@squashfs.org.uk Link: https://lkml.kernel.org/r/20250923220652.568416-2-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Signed-off-by: Andrew Morton Stable-dep-of: 9f1c14c1de1b ("Squashfs: reject negative file sizes in squashfs_read_inode()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8f52c7f38f0f2ee2afc331e6b873acba5e9490a8 Author: Edward Adam Davis Date: Mon Oct 13 18:11:45 2025 -0400 media: mc: Clear minor number before put device [ Upstream commit 8cfc8cec1b4da88a47c243a11f384baefd092a50 ] The device minor should not be cleared after the device is released. Fixes: 9e14868dc952 ("media: mc: Clear minor number reservation at unregistration time") Cc: stable@vger.kernel.org Reported-by: syzbot+031d0cfd7c362817963f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=031d0cfd7c362817963f Tested-by: syzbot+031d0cfd7c362817963f@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil [ moved clear_bit from media_devnode_release callback to media_devnode_unregister before put_device ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba35a5d775799ce5ad60230be97336f2fefd518e Author: Sean Christopherson Date: Mon Oct 13 11:11:40 2025 -0400 KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O [ Upstream commit e750f85391286a4c8100275516973324b621a269 ] When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended "recipient") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Reported-by: syzbot+cc2032ba16cc2018ca25@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68790db4.a00a0220.3af5df.0020.GAE@google.com Fixes: 8a76d7f25f8f ("KVM: x86: Add x86 callback for intercept check") Cc: stable@vger.kernel.org Cc: Jim Mattson Link: https://lore.kernel.org/r/20250715190638.1899116-1-seanjc@google.com Signed-off-by: Sean Christopherson [ is_guest_mode() was open coded ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cef53f320932d24f01249b81f248dc42365ad29a Author: Ma Ke Date: Mon Oct 13 14:34:34 2025 -0400 ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data() [ Upstream commit 4e65bda8273c938039403144730923e77916a3d7 ] wcd934x_codec_parse_data() contains a device reference count leak in of_slim_get_device() where device_find_child() increases the reference count of the device but this reference is not properly decreased in the success path. Add put_device() in wcd934x_codec_parse_data() and add devm_add_action_or_reset() in the probe function, which ensures that the reference count of the device is correctly managed. Memory leak in regmap_init_slimbus() as the allocated regmap is not released when the device is removed. Using devm_regmap_init_slimbus() instead of regmap_init_slimbus() to ensure automatic regmap cleanup on device removal. Calling path: of_slim_get_device() -> of_find_slim_device() -> device_find_child(). As comment of device_find_child() says, 'NOTE: you will need to drop the reference with put_device() after use.'. Found by code review. Cc: stable@vger.kernel.org Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Signed-off-by: Ma Ke Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20250923065212.26660-1-make24@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 82df24ed54a395585f3dc9fd7d0accc844c8a033 Author: Krzysztof Kozlowski Date: Mon Oct 13 14:34:33 2025 -0400 ASoC: codecs: wcd934x: Simplify with dev_err_probe [ Upstream commit fa92f4294283cc7d1f29151420be9e9336182518 ] Replace dev_err() in probe() path with dev_err_probe() to: 1. Make code a bit simpler and easier to read, 2. Do not print messages on deferred probe. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20230418074630.8681-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown Stable-dep-of: 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5ee6157d564309a5e14e99518dcb72480abcb6c Author: Nathan Chancellor Date: Mon Jun 9 15:45:20 2025 -0700 lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older commit 2f13daee2a72bb962f5fd356c3a263a6f16da965 upstream. After commit 6f110a5e4f99 ("Disable SLUB_TINY for build testing"), which causes CONFIG_KASAN to be enabled in allmodconfig again, arm64 allmodconfig builds with clang-17 and older show an instance of -Wframe-larger-than (which breaks the build with CONFIG_WERROR=y): lib/crypto/curve25519-hacl64.c:757:6: error: stack frame size (2336) exceeds limit (2048) in 'curve25519_generic' [-Werror,-Wframe-larger-than] 757 | void curve25519_generic(u8 mypublic[CURVE25519_KEY_SIZE], | ^ When KASAN is disabled, the stack usage is roughly quartered: lib/crypto/curve25519-hacl64.c:757:6: error: stack frame size (608) exceeds limit (128) in 'curve25519_generic' [-Werror,-Wframe-larger-than] 757 | void curve25519_generic(u8 mypublic[CURVE25519_KEY_SIZE], | ^ Using '-Rpass-analysis=stack-frame-layout' shows the following variables and many, many 8-byte spills when KASAN is enabled: Offset: [SP-144], Type: Variable, Align: 8, Size: 40 Offset: [SP-464], Type: Variable, Align: 8, Size: 320 Offset: [SP-784], Type: Variable, Align: 8, Size: 320 Offset: [SP-864], Type: Variable, Align: 32, Size: 80 Offset: [SP-896], Type: Variable, Align: 32, Size: 32 Offset: [SP-1016], Type: Variable, Align: 8, Size: 120 When KASAN is disabled, there are still spills but not at many and the variables list is smaller: Offset: [SP-192], Type: Variable, Align: 32, Size: 80 Offset: [SP-224], Type: Variable, Align: 32, Size: 32 Offset: [SP-344], Type: Variable, Align: 8, Size: 120 Disable KASAN for this file when using clang-17 or older to avoid blowing out the stack, clearing up the warning. Signed-off-by: Nathan Chancellor Acked-by: "Jason A. Donenfeld" Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250609-curve25519-hacl64-disable-kasan-clang-v1-1-08ea0ac5ccff@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 13291e74ba372c3d5c000787c10fc6a6c310a5ea Author: Jan Kara Date: Tue Oct 7 15:49:37 2025 +0200 ext4: free orphan info with kvfree commit 971843c511c3c2f6eda96c6b03442913bfee6148 upstream. Orphan info is now getting allocated with kvmalloc_array(). Free it with kvfree() instead of kfree() to avoid complaints from mm. Reported-by: Chris Mason Fixes: 0a6ce20c1564 ("ext4: verify orphan file size is not too big") Cc: stable@vger.kernel.org Signed-off-by: Jan Kara Message-ID: <20251007134936.7291-2-jack@suse.cz> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a92686e03508f9cff7c2d6b4791fae7baeb33334 Author: Huacai Chen Date: Fri Sep 12 21:54:53 2025 +0200 ACPICA: Allow to skip Global Lock initialization commit feb8ae81b2378b75a99c81d315602ac8918ed382 upstream. Introduce acpi_gbl_use_global_lock, which allows to skip the Global Lock initialization. This is useful for systems without Global Lock (such as loong_arch), so as to avoid error messages during boot phase: ACPI Error: Could not enable global_lock event (20240827/evxfevnt-182) ACPI Error: No response from Global Lock hardware, disabling lock (20240827/evglock-59) Link: https://github.com/acpica/acpica/commit/463cb0fe Signed-off-by: Huacai Chen Signed-off-by: Rafael J. Wysocki Cc: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 3d6269028246f4484bfed403c947a114bb583631 Author: Ahmet Eray Karadag Date: Sat Sep 20 05:13:43 2025 +0300 ext4: guard against EA inode refcount underflow in xattr update commit 57295e835408d8d425bef58da5253465db3d6888 upstream. syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1). That lets the refcount underflow and we proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117 Make the invariant explicit: if the current refcount is non-positive, treat this as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount. Delete the WARN_ONCE() as negative refcounts are now impossible; keep error reporting in ext4_error_inode(). This prevents the underflow and the follow-on orphan/cleanup churn. Reported-by: syzbot+0be4f339a8218d2a5bb1@syzkaller.appspotmail.com Fixes: https://syzbot.org/bug?extid=0be4f339a8218d2a5bb1 Cc: stable@kernel.org Co-developed-by: Albin Babu Varghese Signed-off-by: Albin Babu Varghese Signed-off-by: Ahmet Eray Karadag Message-ID: <20250920021342.45575-1-eraykrdg1@gmail.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 8b1ce292262d7ae49d6888a042516f9f19fbd91a Author: Ojaswin Mujoo Date: Fri Sep 5 13:44:46 2025 +0530 ext4: correctly handle queries for metadata mappings commit 46c22a8bb4cb03211da1100d7ee4a2005bf77c70 upstream. Currently, our handling of metadata is _ambiguous_ in some scenarios, that is, we end up returning unknown if the range only covers the mapping partially. For example, in the following case: $ xfs_io -c fsmap -d 0: 254:16 [0..7]: static fs metadata 8 1: 254:16 [8..15]: special 102:1 8 2: 254:16 [16..5127]: special 102:2 5112 3: 254:16 [5128..5255]: special 102:3 128 4: 254:16 [5256..5383]: special 102:4 128 5: 254:16 [5384..70919]: inodes 65536 6: 254:16 [70920..70967]: unknown 48 ... $ xfs_io -c fsmap -d 24 33 0: 254:16 [24..39]: unknown 16 <--- incomplete reporting $ xfs_io -c fsmap -d 24 33 (With patch) 0: 254:16 [16..5127]: special 102:2 5112 This is because earlier in ext4_getfsmap_meta_helper, we end up ignoring any extent that starts before our queried range, but overlaps it. While the man page [1] is a bit ambiguous on this, this fix makes the output make more sense since we are anyways returning an "unknown" extent. This is also consistent to how XFS does it: $ xfs_io -c fsmap -d ... 6: 254:16 [104..127]: free space 24 7: 254:16 [128..191]: inodes 64 ... $ xfs_io -c fsmap -d 137 150 0: 254:16 [128..191]: inodes 64 <-- full extent returned [1] https://man7.org/linux/man-pages/man2/ioctl_getfsmap.2.html Reported-by: Ritesh Harjani (IBM) Cc: stable@kernel.org Signed-off-by: Ojaswin Mujoo Message-ID: <023f37e35ee280cd9baac0296cbadcbe10995cab.1757058211.git.ojaswin@linux.ibm.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 30abddfe5da6b99e9923502c445514b76bf21111 Author: Yongjian Sun Date: Thu Sep 11 21:30:24 2025 +0800 ext4: increase i_disksize to offset + len in ext4_update_disksize_before_punch() commit 9d80eaa1a1d37539224982b76c9ceeee736510b9 upstream. After running a stress test combined with fault injection, we performed fsck -a followed by fsck -fn on the filesystem image. During the second pass, fsck -fn reported: Inode 131512, end of extent exceeds allowed value (logical block 405, physical block 1180540, len 2) This inode was not in the orphan list. Analysis revealed the following call chain that leads to the inconsistency: ext4_da_write_end() //does not update i_disksize ext4_punch_hole() //truncate folio, keep size ext4_page_mkwrite() ext4_block_page_mkwrite() ext4_block_write_begin() ext4_get_block() //insert written extent without update i_disksize journal commit echo 1 > /sys/block/xxx/device/delete da-write path updates i_size but does not update i_disksize. Then ext4_punch_hole truncates the da-folio yet still leaves i_disksize unchanged(in the ext4_update_disksize_before_punch function, the condition offset + len < size is met). Then ext4_page_mkwrite sees ext4_nonda_switch return 1 and takes the nodioread_nolock path, the folio about to be written has just been punched out, and it’s offset sits beyond the current i_disksize. This may result in a written extent being inserted, but again does not update i_disksize. If the journal gets committed and then the block device is yanked, we might run into this. It should be noted that replacing ext4_punch_hole with ext4_zero_range in the call sequence may also trigger this issue, as neither will update i_disksize under these circumstances. To fix this, we can modify ext4_update_disksize_before_punch to increase i_disksize to min(i_size, offset + len) when both i_size and (offset + len) are greater than i_disksize. Cc: stable@kernel.org Signed-off-by: Yongjian Sun Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Message-ID: <20250911133024.1841027-1-sunyongjian@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 566a1d6084563bd07433025aa23bcea4427de107 Author: Jan Kara Date: Tue Sep 9 13:22:07 2025 +0200 ext4: verify orphan file size is not too big commit 0a6ce20c156442a4ce2a404747bb0fb05d54eeb3 upstream. In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files. Reported-by: syzbot+0b92850d68d9b12934f5@syzkaller.appspotmail.com Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Cc: stable@kernel.org Signed-off-by: Jan Kara Message-ID: <20250909112206.10459-2-jack@suse.cz> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 4716a38d502fef7a31dd17b3991f22bd0b0f5095 Author: Olga Kornievskaia Date: Thu Aug 21 16:31:46 2025 -0400 nfsd: nfserr_jukebox in nlm_fopen should lead to a retry commit a082e4b4d08a4a0e656d90c2c05da85f23e6d0c9 upstream. When v3 NLM request finds a conflicting delegation, it triggers a delegation recall and nfsd_open fails with EAGAIN. nfsd_open then translates EAGAIN into nfserr_jukebox. In nlm_fopen, instead of returning nlm_failed for when there is a conflicting delegation, drop this NLM request so that the client retries. Once delegation is recalled and if a local lock is claimed, a retry would lead to nfsd returning a nlm_lck_blocked error or a successful nlm lock. Fixes: d343fce148a4 ("[PATCH] knfsd: Allow lockd to drop replies as appropriate") Cc: stable@vger.kernel.org # v6.6 Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 958a45b710b067772c0297e59c0721948d25a903 Author: Thorsten Blum Date: Wed Aug 6 03:10:01 2025 +0200 NFSD: Fix destination buffer size in nfsd4_ssc_setup_dul() commit ab1c282c010c4f327bd7addc3c0035fd8e3c1721 upstream. Commit 5304877936c0 ("NFSD: Fix strncpy() fortify warning") replaced strncpy(,, sizeof(..)) with strlcpy(,, sizeof(..) - 1), but strlcpy() already guaranteed NUL-termination of the destination buffer and subtracting one byte potentially truncated the source string. The incorrect size was then carried over in commit 72f78ae00a8e ("NFSD: move from strlcpy with unused retval to strscpy") when switching from strlcpy() to strscpy(). Fix this off-by-one error by using the full size of the destination buffer again. Cc: stable@vger.kernel.org Fixes: 5304877936c0 ("NFSD: Fix strncpy() fortify warning") Signed-off-by: Thorsten Blum Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8f1ca1f373c9e401deb59417deddbc2afbea9a2a Author: Li RongQing Date: Thu Aug 14 18:23:33 2025 +0800 mm/hugetlb: early exit from hugetlb_pages_alloc_boot() when max_huge_pages=0 commit b322e88b3d553e85b4e15779491c70022783faa4 upstream. Optimize hugetlb_pages_alloc_boot() to return immediately when max_huge_pages is 0, avoiding unnecessary CPU cycles and the below log message when hugepages aren't configured in the kernel command line. [ 3.702280] HugeTLB: allocation took 0ms with hugepage_allocation_threads=32 Link: https://lkml.kernel.org/r/20250814102333.4428-1-lirongqing@baidu.com Signed-off-by: Li RongQing Reviewed-by: Dev Jain Tested-by: Dev Jain Reviewed-by: Jane Chu Acked-by: David Hildenbrand Cc: Muchun Song Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3575087197f0e5cc1a1a9b50af91250559717a8a Author: Thadeu Lima de Souza Cascardo Date: Thu Aug 14 14:22:45 2025 -0300 mm/page_alloc: only set ALLOC_HIGHATOMIC for __GPF_HIGH allocations commit 6a204d4b14c99232e05d35305c27ebce1c009840 upstream. Commit 524c48072e56 ("mm/page_alloc: rename ALLOC_HIGH to ALLOC_MIN_RESERVE") is the start of a series that explains how __GFP_HIGH, which implies ALLOC_MIN_RESERVE, is going to be used instead of __GFP_ATOMIC for high atomic reserves. Commit eb2e2b425c69 ("mm/page_alloc: explicitly record high-order atomic allocations in alloc_flags") introduced ALLOC_HIGHATOMIC for such allocations of order higher than 0. It still used __GFP_ATOMIC, though. Then, commit 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves") just turned that check for !__GFP_DIRECT_RECLAIM, ignoring that high atomic reserves were expected to test for __GFP_HIGH. This leads to high atomic reserves being added for high-order GFP_NOWAIT allocations and others that clear __GFP_DIRECT_RECLAIM, which is unexpected. Later, those reserves lead to 0-order allocations going to the slow path and starting reclaim. From /proc/pagetypeinfo, without the patch: Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA32, type HighAtomic 1 8 10 9 7 3 0 0 0 0 0 Node 0, zone Normal, type HighAtomic 64 20 12 5 0 0 0 0 0 0 0 With the patch: Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA32, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Link: https://lkml.kernel.org/r/20250814172245.1259625-1-cascardo@igalia.com Fixes: 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves") Signed-off-by: Thadeu Lima de Souza Cascardo Tested-by: Helen Koike Reviewed-by: Vlastimil Babka Tested-by: Sergey Senozhatsky Acked-by: Michal Hocko Cc: Mel Gorman Cc: Matthew Wilcox Cc: NeilBrown Cc: Thierry Reding Cc: Brendan Jackman Cc: Johannes Weiner Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 67cb933edb7c6e8d4120f3d9a49c5fdbec2b4ac7 Author: Muhammad Usama Anjum Date: Tue Jul 22 10:31:21 2025 +0500 wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again commit 32be3ca4cf78b309dfe7ba52fe2d7cc3c23c5634 upstream. Don't deinitialize and reinitialize the HAL helpers. The dma memory is deallocated and there is high possibility that we'll not be able to get the same memory allocated from dma when there is high memory pressure. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org Cc: Baochen Qiang Reviewed-by: Baochen Qiang Signed-off-by: Muhammad Usama Anjum Link: https://patch.msgid.link/20250722053121.1145001-1-usama.anjum@collabora.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit ac7a9229d1ff1fffdae99a8b9455b3e1e33701b4 Author: Matthieu Baerts (NGI0) Date: Thu Sep 25 12:32:37 2025 +0200 selftests: mptcp: join: validate C-flag + def limit commit 008385efd05e04d8dff299382df2e8be0f91d8a0 upstream. The previous commit adds an exception for the C-flag case. The 'mptcp_join.sh' selftest is extended to validate this case. In this subtest, there is a typical CDN deployment with a client where MPTCP endpoints have been 'automatically' configured: - the server set net.mptcp.allow_join_initial_addr_port=0 - the client has multiple 'subflow' endpoints, and the default limits: not accepting ADD_ADDRs. Without the parent patch, the client is not able to establish new subflows using its 'subflow' endpoints. The parent commit fixes that. 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: df377be38725 ("mptcp: add deny_join_id0 in mptcp_options_received") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250925-net-next-mptcp-c-flag-laminar-v1-2-ad126cc47c6b@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 32e5dbaaa9b714f885a459ba222ab9aabc5b366f Author: Sean Christopherson Date: Fri Aug 8 10:23:57 2025 -0700 x86/umip: Fix decoding of register forms of 0F 01 (SGDT and SIDT aliases) commit 27b1fd62012dfe9d3eb8ecde344d7aa673695ecf upstream. Filter out the register forms of 0F 01 when determining whether or not to emulate in response to a potential UMIP violation #GP, as SGDT and SIDT only accept memory operands. The register variants of 0F 01 are used to encode instructions for things like VMX and SGX, i.e. not checking the Mod field would cause the kernel to incorrectly emulate on #GP, e.g. due to a CPL violation on VMLAUNCH. Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions") Signed-off-by: Sean Christopherson Signed-off-by: Borislav Petkov (AMD) Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit efc947f836e215c4e9a1f52d922819652d848ef7 Author: Sean Christopherson Date: Fri Aug 8 10:23:56 2025 -0700 x86/umip: Check that the instruction opcode is at least two bytes commit 32278c677947ae2f042c9535674a7fff9a245dd3 upstream. When checking for a potential UMIP violation on #GP, verify the decoder found at least two opcode bytes to avoid false positives when the kernel encounters an unknown instruction that starts with 0f. Because the array of opcode.bytes is zero-initialized by insn_init(), peeking at bytes[1] will misinterpret garbage as a potential SLDT or STR instruction, and can incorrectly trigger emulation. E.g. if a VPALIGNR instruction 62 83 c5 05 0f 08 ff vpalignr xmm17{k5},xmm23,XMMWORD PTR [r8],0xff hits a #GP, the kernel emulates it as STR and squashes the #GP (and corrupts the userspace code stream). Arguably the check should look for exactly two bytes, but no three byte opcodes use '0f 00 xx' or '0f 01 xx' as an escape, i.e. it should be impossible to get a false positive if the first two opcode bytes match '0f 00' or '0f 01'. Go with a more conservative check with respect to the existing code to minimize the chances of breaking userspace, e.g. due to decoder weirdness. Analyzed by Nick Bray . Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions") Reported-by: Dan Snyder Signed-off-by: Sean Christopherson Signed-off-by: Borislav Petkov (AMD) Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8fc01985b735b1c2d6e263564e27839497c87b33 Author: Pratyush Yadav Date: Sat Sep 6 00:29:56 2025 +0530 spi: cadence-quadspi: Flush posted register writes before DAC access commit 1ad55767e77a853c98752ed1e33b68049a243bd7 upstream. cqspi_read_setup() and cqspi_write_setup() program the address width as the last step in the setup. This is likely to be immediately followed by a DAC region read/write. On TI K3 SoCs the DAC region is on a different endpoint from the register region. This means that the order of the two operations is not guaranteed, and they might be reordered at the interconnect level. It is possible that the DAC read/write goes through before the address width update goes through. In this situation if the previous command used a different address width the OSPI command is sent with the wrong number of address bytes, resulting in an invalid command and undefined behavior. Read back the size register to make sure the write gets flushed before accessing the DAC region. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") CC: stable@vger.kernel.org Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav Signed-off-by: Santhosh Kumar K Message-ID: <20250905185958.3575037-3-s-k6@ti.com> Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c1d4f599a79bd460268aac82119f5e6d54088029 Author: Pratyush Yadav Date: Sat Sep 6 00:29:55 2025 +0530 spi: cadence-quadspi: Flush posted register writes before INDAC access commit 29e0b471ccbd674d20d4bbddea1a51e7105212c5 upstream. cqspi_indirect_read_execute() and cqspi_indirect_write_execute() first set the enable bit on APB region and then start reading/writing to the AHB region. On TI K3 SoCs these regions lie on different endpoints. This means that the order of the two operations is not guaranteed, and they might be reordered at the interconnect level. It is possible for the AHB write to be executed before the APB write to enable the indirect controller, causing the transaction to be invalid and the write erroring out. Read back the APB region write before accessing the AHB region to make sure the write got flushed and the race condition is eliminated. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") CC: stable@vger.kernel.org Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav Signed-off-by: Santhosh Kumar K Message-ID: <20250905185958.3575037-2-s-k6@ti.com> Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4e708563de36090c09aa1d6b4d98776fb236e667 Author: Vidya Sagar Date: Mon Sep 22 16:08:26 2025 +0200 PCI: tegra194: Handle errors in BPMP response commit f8c9ad46b00453a8c075453f3745f8d263f44834 upstream. The return value from tegra_bpmp_transfer() indicates the success or failure of the IPC transaction with BPMP. If the transaction succeeded, we also need to check the actual command's result code. If we don't have error handling for tegra_bpmp_transfer(), we will set the pcie->ep_state to EP_STATE_ENABLED even when the tegra_bpmp_transfer() command fails. Thus, the pcie->ep_state will get out of sync with reality, and any further PERST# assert + deassert will be a no-op and will not trigger the hardware initialization sequence. This is because pex_ep_event_pex_rst_deassert() checks the current pcie->ep_state, and does nothing if the current state is already EP_STATE_ENABLED. Thus, it is important to have error handling for tegra_bpmp_transfer(), such that the pcie->ep_state can not get out of sync with reality, so that we will try to initialize the hardware not only during the first PERST# assert + deassert, but also during any succeeding PERST# assert + deassert. One example where this fix is needed is when using a rock5b as host. During the initial PERST# assert + deassert (triggered by the bootloader on the rock5b) pex_ep_event_pex_rst_deassert() will get called, but for some unknown reason, the tegra_bpmp_transfer() call to initialize the PHY fails. Once Linux has been loaded on the rock5b, the PCIe driver will once again assert + deassert PERST#. However, without tegra_bpmp_transfer() error handling, this second PERST# assert + deassert will not trigger the hardware initialization sequence. With tegra_bpmp_transfer() error handling, the second PERST# assert + deassert will once again trigger the hardware to be initialized and this time the tegra_bpmp_transfer() succeeds. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar [cassel: improve commit log] Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Jon Hunter Acked-by: Thierry Reding Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250922140822.519796-8-cassel@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1095b3af487f312e83846cc49b570701a12aeb1c Author: Niklas Cassel Date: Mon Sep 22 16:08:24 2025 +0200 PCI: tegra194: Fix broken tegra_pcie_ep_raise_msi_irq() commit b640d42a6ac9ba01abe65ec34f7c73aaf6758ab8 upstream. The pci_epc_raise_irq() supplies a MSI or MSI-X interrupt number in range (1-N), as per the pci_epc_raise_irq() kdoc, where N is 32 for MSI. But tegra_pcie_ep_raise_msi_irq() incorrectly uses the interrupt number as the MSI vector. This causes wrong MSI vector to be triggered, leading to the failure of PCI endpoint Kselftest MSI_TEST test case. To fix this issue, convert the interrupt number to MSI vector. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250922140822.519796-6-cassel@kernel.org Signed-off-by: Greg Kroah-Hartman commit b2e1a984f2fcdca91bae5ad3661504df6abdff06 Author: Marek Vasut Date: Tue Sep 9 18:26:25 2025 +0200 PCI: rcar-host: Convert struct rcar_msi mask_lock into raw spinlock commit 5ed35b4d490d8735021cce9b715b62a418310864 upstream. The rcar_msi_irq_unmask() function may be called from a PCI driver request_threaded_irq() function. This triggers kernel/irq/manage.c __setup_irq() which locks raw spinlock &desc->lock descriptor lock and with that descriptor lock held, calls rcar_msi_irq_unmask(). Since the &desc->lock descriptor lock is a raw spinlock, and the rcar_msi .mask_lock is not a raw spinlock, this setup triggers 'BUG: Invalid wait context' with CONFIG_PROVE_RAW_LOCK_NESTING=y. Use scoped_guard() to simplify the locking. Fixes: 83ed8d4fa656 ("PCI: rcar: Convert to MSI domains") Reported-by: Duy Nguyen Reported-by: Thuan Nguyen Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Geert Uytterhoeven Acked-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250909162707.13927-2-marek.vasut+renesas@mailbox.org Signed-off-by: Greg Kroah-Hartman commit bd904d46a51aa2a1c8100ec3052aa039df26a039 Author: Marek Vasut Date: Tue Sep 9 18:26:24 2025 +0200 PCI: rcar-host: Drop PMSR spinlock commit 0a8f173d9dad13930d5888505dc4c4fd6a1d4262 upstream. The pmsr_lock spinlock used to be necessary to synchronize access to the PMSR register, because that access could have been triggered from either config space access in rcar_pcie_config_access() or an exception handler rcar_pcie_aarch32_abort_handler(). The rcar_pcie_aarch32_abort_handler() case is no longer applicable since commit 6e36203bc14c ("PCI: rcar: Use PCI_SET_ERROR_RESPONSE after read which triggered an exception"), which performs more accurate, controlled invocation of the exception, and a fixup. This leaves rcar_pcie_config_access() as the only call site from which rcar_pcie_wakeup() is called. The rcar_pcie_config_access() can only be called from the controller struct pci_ops .read and .write callbacks, and those are serialized in drivers/pci/access.c using raw spinlock 'pci_lock' . It should be noted that CONFIG_PCI_LOCKLESS_CONFIG is never set on this platform. Since the 'pci_lock' is a raw spinlock , and the 'pmsr_lock' is not a raw spinlock, this constellation triggers 'BUG: Invalid wait context' with CONFIG_PROVE_RAW_LOCK_NESTING=y . Remove the pmsr_lock to fix the locking. Fixes: a115b1bd3af0 ("PCI: rcar: Add L1 link state fix into data abort hook") Reported-by: Duy Nguyen Reported-by: Thuan Nguyen Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Reviewed-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250909162707.13927-1-marek.vasut+renesas@mailbox.org Signed-off-by: Greg Kroah-Hartman commit 25bfff344bdb39103e04520facccce355095c14c Author: Siddharth Vadapalli Date: Fri Sep 12 15:37:58 2025 +0530 PCI: keystone: Use devm_request_irq() to free "ks-pcie-error-irq" on exit commit e51d05f523e43ce5d2bad957943a2b14f68078cd upstream. Commit under Fixes introduced the IRQ handler for "ks-pcie-error-irq". The interrupt is acquired using "request_irq()" but is never freed if the driver exits due to an error. Although the section in the driver that invokes "request_irq()" has moved around over time, the issue hasn't been addressed until now. Fix this by using "devm_request_irq()" which automatically frees the interrupt if the driver exits. Fixes: 025dd3daeda7 ("PCI: keystone: Add error IRQ handler") Reported-by: Jiri Slaby Closes: https://lore.kernel.org/r/3d3a4b52-e343-42f3-9d69-94c259812143@kernel.org Signed-off-by: Siddharth Vadapalli Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250912100802.3136121-2-s-vadapalli@ti.com Signed-off-by: Greg Kroah-Hartman commit a4b802f1a6055fec4596e21ab7f0f48d1492b9b0 Author: Lukas Wunner Date: Wed Aug 27 15:41:09 2025 +0200 PCI/AER: Support errors introduced by PCIe r6.0 commit 6633875250b38b18b8638cf01e695de031c71f02 upstream. PCIe r6.0 defined five additional errors in the Uncorrectable Error Status, Mask and Severity Registers (PCIe r7.0 sec 7.8.4.2ff). lspci has been supporting them since commit 144b0911cc0b ("ls-ecaps: extend decode support for more fields for AER CE and UE status"): https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/commit/?id=144b0911cc0b Amend the AER driver to recognize them as well, instead of logging them as "Unknown Error Bit". Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/21f1875b18d4078c99353378f37dcd6b994f6d4e.1756301211.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 44271198ed149ab28885e77905d7b7e784feeea5 Author: Niklas Schnelle Date: Thu Aug 7 15:55:38 2025 +0200 PCI/AER: Fix missing uevent on recovery when a reset is requested commit bbf7d0468d0da71d76cc6ec9bc8a224325d07b6b upstream. Since commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") AER uses the result of error_detected() as parameter to pci_uevent_ers(). As pci_uevent_ers() however does not handle PCI_ERS_RESULT_NEED_RESET this results in a missing uevent for the beginning of recovery if drivers request a reset. Fix this by treating PCI_ERS_RESULT_NEED_RESET as beginning recovery. Fixes: 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250807-add_err_uevents-v5-1-adf85b0620b0@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit fbae9327cb04954ab7da4dbfbb71be274ae0ebb8 Author: Lukas Wunner Date: Wed Aug 13 07:11:02 2025 +0200 PCI/ERR: Fix uevent on failure to recover commit 1cbc5e25fb70e942a7a735a1f3d6dd391afc9b29 upstream. Upon failure to recover from a PCIe error through AER, DPC or EDR, a uevent is sent to inform user space about disconnection of the bridge whose subordinate devices failed to recover. However the bridge itself is not disconnected. Instead, a uevent should be sent for each of the subordinate devices. Only if the "bridge" happens to be a Root Complex Event Collector or Integrated Endpoint does it make sense to send a uevent for it (because there are no subordinate devices). Right now if there is a mix of subordinate devices with and without pci_error_handlers, a BEGIN_RECOVERY event is sent for those with pci_error_handlers but no FAILED_RECOVERY event is ever sent for them afterwards. Fix it. Fixes: 856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v4.16+ Link: https://patch.msgid.link/68fc527a380821b5d861dd554d2ce42cb739591c.1755008151.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit a24219172456f035d886857e265ca24c85b167c8 Author: Niklas Schnelle Date: Tue Aug 26 10:52:08 2025 +0200 PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV commit 05703271c3cdcc0f2a8cf6ebdc45892b8ca83520 upstream. Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking. Fixes: 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Reviewed-by: Julian Ruess Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250826-pci_fix_sriov_disable-v1-1-2d0bc938f2a3@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 2a0f0dff043a4aa0f5c268bfb85244784d5e75cd Author: Brian Norris Date: Wed Sep 24 09:57:11 2025 -0700 PCI/sysfs: Ensure devices are powered for config reads commit 48991e4935078b05f80616c75d1ee2ea3ae18e58 upstream. The "max_link_width", "current_link_speed", "current_link_width", "secondary_bus_number", and "subordinate_bus_number" sysfs files all access config registers, but they don't check the runtime PM state. If the device is in D3cold or a parent bridge is suspended, we may see -EINVAL, bogus values, or worse, depending on implementation details. Wrap these access in pci_config_pm_runtime_{get,put}() like most of the rest of the similar sysfs attributes. Notably, "max_link_speed" does not access config registers; it returns a cached value since d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds"). Fixes: 56c1af4606f0 ("PCI: Add sysfs max_link_speed/width, current_link_speed/width, etc") Signed-off-by: Brian Norris Signed-off-by: Brian Norris Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250924095711.v2.1.Ibb5b6ca1e2c059e04ec53140cd98a44f2684c668@changeid Signed-off-by: Greg Kroah-Hartman commit 9a4f8f6b08d6618f3ca52031bc99e4a7a49bd67e Author: Marek Vasut Date: Mon Sep 22 17:07:48 2025 +0200 PCI: tegra: Convert struct tegra_msi mask_lock into raw spinlock commit 26fda92d3b56bf44a02bcb4001c5a5548e0ae8ee upstream. The tegra_msi_irq_unmask() function may be called from a PCI driver request_threaded_irq() function. This triggers kernel/irq/manage.c __setup_irq() which locks raw spinlock &desc->lock descriptor lock and with that descriptor lock held, calls tegra_msi_irq_unmask(). Since the &desc->lock descriptor lock is a raw spinlock, and the tegra_msi .mask_lock is not a raw spinlock, this setup triggers 'BUG: Invalid wait context' with CONFIG_PROVE_RAW_LOCK_NESTING=y. Use scoped_guard() to simplify the locking. Fixes: 2c99e55f7955 ("PCI: tegra: Convert to MSI domains") Reported-by: Geert Uytterhoeven Closes: https://patchwork.kernel.org/project/linux-pci/patch/20250909162707.13927-2-marek.vasut+renesas@mailbox.org/#26574451 Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250922150811.88450-1-marek.vasut+renesas@mailbox.org Signed-off-by: Greg Kroah-Hartman commit fcd4c9075eca28d00808d580912bbe64c8b33010 Author: Sean Christopherson Date: Tue Aug 19 15:29:44 2025 -0700 rseq/selftests: Use weak symbol reference, not definition, to link with glibc commit a001cd248ab244633c5fabe4f7c707e13fc1d1cc upstream. Add "extern" to the glibc-defined weak rseq symbols to convert the rseq selftest's usage from weak symbol definitions to weak symbol _references_. Effectively re-defining the glibc symbols wreaks havoc when building with -fno-common, e.g. generates segfaults when running multi-threaded programs, as dynamically linked applications end up with multiple versions of the symbols. Building with -fcommon, which until recently has the been the default for GCC and clang, papers over the bug by allowing the linker to resolve the weak/tentative definition to glibc's "real" definition. Note, the symbol itself (or rather its address), not the value of the symbol, is set to 0/NULL for unresolved weak symbol references, as the symbol doesn't exist and thus can't have a value. Check for a NULL rseq size pointer to handle the scenario where the test is statically linked against a libc that doesn't support rseq in any capacity. Fixes: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+") Reported-by: Thomas Gleixner Suggested-by: Florian Weimer Signed-off-by: Sean Christopherson Signed-off-by: Thomas Gleixner Reviewed-by: Mathieu Desnoyers Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/87frdoybk4.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit 562d9af5c25c1366a9eb13fe2c7449fc2e90b6b7 Author: Esben Haabendal Date: Fri May 16 09:23:35 2025 +0200 rtc: interface: Fix long-standing race when setting alarm commit 795cda8338eab036013314dbc0b04aae728880ab upstream. As described in the old comment dating back to commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") from 2010, we have been living with a race window when setting alarm with an expiry in the near future (i.e. next second). With 1 second resolution, it can happen that the second ticks after the check for the timer having expired, but before the alarm is actually set. When this happen, no alarm IRQ is generated, at least not with some RTC chips (isl12022 is an example of this). With UIE RTC timer being implemented on top of alarm irq, being re-armed every second, UIE will occasionally fail to work, as an alarm irq lost due to this race will stop the re-arming loop. For now, I have limited the additional expiry check to only be done for alarms set to next seconds. I expect it should be good enough, although I don't know if we can now for sure that systems with loads could end up causing the same problems for alarms set 2 seconds or even longer in the future. I haven't been able to reproduce the problem with this check in place. Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-1-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 545c131a658ab4e7bff492a33e78c7d236144a3c Author: Esben Haabendal Date: Fri May 16 09:23:39 2025 +0200 rtc: interface: Ensure alarm irq is enabled when UIE is enabled commit 9db26d5855d0374d4652487bfb5aacf40821c469 upstream. When setting a normal alarm, user-space is responsible for using RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled. But when RTC_UIE_ON is used, interrupts must be enabled so that the requested irq events are generated. When RTC_UIE_OFF is used, alarm irq is disabled if there are no other alarms queued, so this commit brings symmetry to that. Signed-off-by: Esben Haabendal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-5-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 1ca1d3f733d63ee35a6caf7f3335edd5fa382a73 Author: Zhen Ni Date: Wed Aug 6 10:55:38 2025 +0800 memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe commit 6744085079e785dae5f7a2239456135407c58b25 upstream. The of_platform_populate() call at the end of the function has a possible failure path, causing a resource leak. Replace of_iomap() with devm_platform_ioremap_resource() to ensure automatic cleanup of srom->reg_base. This issue was detected by smatch static analysis: drivers/memory/samsung/exynos-srom.c:155 exynos_srom_probe()warn: 'srom->reg_base' from of_iomap() not released on lines: 155. Fixes: 8ac2266d8831 ("memory: samsung: exynos-srom: Add support for bank configuration") Cc: stable@vger.kernel.org Signed-off-by: Zhen Ni Link: https://lore.kernel.org/r/20250806025538.306593-1-zhen.ni@easystack.cn Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 7bfefdc604d72c908008fe56a6333ccc0fbfd70e Author: Rex Chen Date: Mon Jul 28 17:22:29 2025 +0900 mmc: core: SPI mode remove cmd7 commit fec40f44afdabcbc4a7748e4278f30737b54bb1a upstream. SPI mode doesn't support cmd7, so remove it in mmc_sdio_alive() and confirm if sdio is active by checking CCCR register value is available or not. Signed-off-by: Rex Chen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250728082230.1037917-2-rex.chen_1@nxp.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 83030b9faaef399699fb116b1d7b81bd18a15bac Author: Linus Walleij Date: Tue Sep 16 18:07:37 2025 +0200 mtd: rawnand: fsmc: Default to autodetect buswidth commit b8df622cf7f6808c85764e681847150ed6d85f3d upstream. If you don't specify buswidth 2 (16 bits) in the device tree, FSMC doesn't even probe anymore: fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro 10100000.flash nand: bus width 8 instead of 16 bits nand: No NAND device found fsmc-nand 10100000.flash: probe with driver fsmc-nand failed with error -22 With this patch to use autodetection unless buswidth is specified, the device is properly detected again: fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro NAND 128MiB 1,8V 16-bit nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 fsmc-nand 10100000.flash: Using 1-bit HW ECC scheme Scanning device for bad blocks I don't know where or how this happened, I think some change in the nand core. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit f40405ccfb87b71175f2d5d004c0b8a0aebcc2cf Author: Miaoqian Lin Date: Fri Aug 29 16:30:15 2025 +0800 xtensa: simdisk: add input size check in proc_write_simdisk commit 5d5f08fd0cd970184376bee07d59f635c8403f63 upstream. A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 ("netdevsim: prevent bad user input in nsim_dev_health_break_write()") Fixes: b6c7e873daf7 ("xtensa: ISS: add host file-based simulated disk") Fixes: 16e5c1fc3604 ("convert a bunch of open-coded instances of memdup_user_nul()") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Message-Id: <20250829083015.1992751-1-linmq006@gmail.com> Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit ccf6af67347d2a2d0198e66634a469c2f8d14a10 Author: Ma Ke Date: Sat Sep 20 20:53:12 2025 +0800 sparc: fix error handling in scan_one_device() commit 302c04110f0ce70d25add2496b521132548cd408 upstream. Once of_device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). Calling path: of_device_register() -> of_device_add() -> device_add(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable@vger.kernel.org Fixes: cf44bbc26cf1 ("[SPARC]: Beginnings of generic of_device framework.") Signed-off-by: Ma Ke Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Greg Kroah-Hartman commit d2a7b3e29ff0c788f4253a8a7db0c84d36c9800a Author: Anthony Yznaga Date: Tue Jul 15 18:24:46 2025 -0700 sparc64: fix hugetlb for sun4u commit 6fd44a481b3c6111e4801cec964627791d0f3ec5 upstream. An attempt to exercise sparc hugetlb code in a sun4u-based guest running under qemu results in the guest hanging due to being stuck in a trap loop. This is due to invalid hugetlb TTEs being installed that do not have the expected _PAGE_PMD_HUGE and page size bits set. Although the breakage has gone apparently unnoticed for several years, fix it now so there is the option to exercise sparc hugetlb code under qemu. This can be useful because sun4v support in qemu does not support linux guests currently and sun4v-based hardware resources may not be readily available. Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs tests on a qemu guest running Debian 13. Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support") Cc: stable@vger.kernel.org Signed-off-by: Anthony Yznaga Tested-by: John Paul Adrian Glaubitz Reviewed-by: John Paul Adrian Glaubitz Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20250716012446.10357-1-anthony.yznaga@oracle.com Signed-off-by: Andreas Larsson Signed-off-by: Greg Kroah-Hartman commit 9c05d44ec24126fc283835b68f82dba3ae985209 Author: Eric Biggers Date: Mon Aug 18 13:54:23 2025 -0700 sctp: Fix MAC comparison to be constant-time commit dd91c79e4f58fbe2898dac84858033700e0e99fb upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Link: https://patch.msgid.link/20250818205426.30222-3-ebiggers@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52f37ce2d523959e8a2a1a135c869f72044ecb15 Author: Thorsten Blum Date: Fri Sep 19 11:26:37 2025 +0200 scsi: hpsa: Fix potential memory leak in hpsa_big_passthru_ioctl() commit b81296591c567b12d3873b05a37b975707959b94 upstream. Replace kmalloc() followed by copy_from_user() with memdup_user() to fix a memory leak that occurs when copy_from_user(buff[sg_used],,) fails and the 'cleanup1:' path does not free the memory for 'buff[sg_used]'. Using memdup_user() avoids this by freeing the memory internally. Since memdup_user() already allocates memory, use kzalloc() in the else branch instead of manually zeroing 'buff[sg_used]' using memset(0). Cc: stable@vger.kernel.org Fixes: edd163687ea5 ("[SCSI] hpsa: add driver for HP Smart Array controllers.") Signed-off-by: Thorsten Blum Acked-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 77a5786c26903b11e3161be4c48c3027c622f140 Author: Harshit Agarwal Date: Tue Apr 8 04:50:21 2025 +0000 sched/deadline: Fix race in push_dl_task() commit 8fd5485fb4f3d9da3977fd783fcb8e5452463420 upstream. When a CPU chooses to call push_dl_task and picks a task to push to another CPU's runqueue then it will call find_lock_later_rq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Please go through the original rt change for more details on the issue. To fix this, after the lock is obtained inside the find_lock_later_rq, it ensures that the task is still at the head of pushable tasks list. Also removed some checks that are no longer needed with the addition of this new check. However, the new check of pushable tasks list only applies when find_lock_later_rq is called by push_dl_task. For the other caller i.e. dl_task_offline_migration, existing checks are used. Signed-off-by: Harshit Agarwal Signed-off-by: Peter Zijlstra (Intel) Acked-by: Juri Lelli Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250408045021.3283624-1-harshit@nutanix.com Signed-off-by: Greg Kroah-Hartman commit fd017aabd4273216ed4223f17991fc087163771f Author: Jisheng Zhang Date: Tue Aug 19 19:42:24 2025 +0800 pwm: berlin: Fix wrong register in suspend/resume commit 3a4b9d027e4061766f618292df91760ea64a1fcc upstream. The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume. Fixes: bbf0722c1c66 ("pwm: berlin: Add suspend/resume support") Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20250819114224.31825-1-jszhang@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit da285b7e8c31052cb9bb8562eac80b443747594a Author: Nam Cao Date: Mon Aug 4 12:07:27 2025 +0200 powerpc/pseries/msi: Fix potential underflow and leak issue commit 3443ff3be6e59b80d74036bb39f5b6409eb23cc9 upstream. pseries_irq_domain_alloc() allocates interrupts at parent's interrupt domain. If it fails in the progress, all allocated interrupts are freed. The number of successfully allocated interrupts so far is stored "i". However, "i - 1" interrupts are freed. This is broken: - One interrupt is not be freed - If "i" is zero, "i - 1" wraps around Correct the number of freed interrupts to 'i'. Fixes: a5f3d2c17b07 ("powerpc/pseries/pci: Add MSI domains") Signed-off-by: Nam Cao Cc: stable@vger.kernel.org Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/a980067f2b256bf716b4cd713bc1095966eed8cd.1754300646.git.namcao@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 8fc674976f57a680eb1276c95c9c94798166246e Author: Nam Cao Date: Mon Aug 4 12:07:28 2025 +0200 powerpc/powernv/pci: Fix underflow and leak issue commit a39087905af9ffecaa237a918a2c03a04e479934 upstream. pnv_irq_domain_alloc() allocates interrupts at parent's interrupt domain. If it fails in the progress, all allocated interrupts are freed. The number of successfully allocated interrupts so far is stored "i". However, "i - 1" interrupts are freed. This is broken: - One interrupt is not be freed - If "i" is zero, "i - 1" wraps around Correct the number of freed interrupts to "i". Fixes: 0fcfe2247e75 ("powerpc/powernv/pci: Add MSI domains") Signed-off-by: Nam Cao Cc: stable@vger.kernel.org Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/70f8debe8688e0b467367db769b71c20146a836d.1754300646.git.namcao@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 07f4a3a9cb69ec09b6625663684cc8444686b70d Author: Dzmitry Sankouski Date: Thu Sep 18 20:06:45 2025 +0300 power: supply: max77976_charger: fix constant current reporting commit ee6cd8f3e28ee5a929c3b67c01a350f550f9b73a upstream. CHARGE_CONTROL_LIMIT is a wrong property to report charge current limit, because `CHARGE_*` attributes represents capacity, not current. The correct attribute to report and set charge current limit is CONSTANT_CHARGE_CURRENT. Rename CHARGE_CONTROL_LIMIT to CONSTANT_CHARGE_CURRENT. Cc: stable@vger.kernel.org Fixes: 715ecbc10d6a ("power: supply: max77976: add Maxim MAX77976 charger driver") Signed-off-by: Dzmitry Sankouski Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 60cb35d82ea05e08a095b608edb22bf12562ad2c Author: Georg Gottleuber Date: Tue Jul 1 22:55:49 2025 +0200 nvme-pci: Add TUXEDO IBS Gen8 to Samsung sleep quirk commit eeaed48980a7aeb0d3d8b438185d4b5a66154ff9 upstream. On the TUXEDO InfinityBook S Gen8, a Samsung 990 Evo NVMe leads to a high power consumption in s2idle sleep (3.5 watts). This patch applies 'Force No Simple Suspend' quirk to achieve a sleep with a lower power consumption, typically around 1 watts. Signed-off-by: Georg Gottleuber Signed-off-by: Werner Sembach Cc: stable@vger.kernel.org Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 4536be48e06f0bf8c1ae3846f0346ba97af2ed9d Author: John David Anglin Date: Tue Aug 5 11:35:30 2025 -0400 parisc: Remove spurious if statement from raw_copy_from_user() commit 16794e524d310780163fdd49d0bf7fac30f8dbc8 upstream. Accidently introduced in commit 91428ca9320e. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Fixes: 91428ca9320e ("parisc: Check region is readable by user in raw_copy_from_user()") Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Greg Kroah-Hartman commit d0ef086c786ec083b12323b97a96bef705174548 Author: Sam James Date: Wed Oct 1 23:58:40 2025 +0100 parisc: don't reference obsolete termio struct for TC* constants commit 8ec5a066f88f89bd52094ba18792b34c49dcd55a upstream. Similar in nature to ab107276607af90b13a5994997e19b7b9731e251. glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Co-authored-by: Stian Halseth Cc: stable@vger.kernel.org Signed-off-by: Sam James Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 398ea8839ab71e3d2640923d766c72347c83e87b Author: Askar Safin Date: Mon Aug 25 18:12:33 2025 +0000 openat2: don't trigger automounts with RESOLVE_NO_XDEV commit 042a60680de43175eb4df0977ff04a4eba9da082 upstream. openat2 had a bug: if we pass RESOLVE_NO_XDEV, then openat2 doesn't traverse through automounts, but may still trigger them. (See the link for full bug report with reproducer.) This commit fixes this bug. Link: https://lore.kernel.org/linux-fsdevel/20250817075252.4137628-1-safinaskar@zohomail.com/ Fixes: fddb5d430ad9fa91b49b1 ("open: introduce openat2(2) syscall") Reviewed-by: Aleksa Sarai Cc: stable@vger.kernel.org Signed-off-by: Askar Safin Link: https://lore.kernel.org/20250825181233.2464822-5-safinaskar@zohomail.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 083f76a7b361e3a5a2c35916231cea62db816688 Author: Johan Hovold Date: Wed Sep 24 10:02:07 2025 +0200 lib/genalloc: fix device leak in of_gen_pool_get() commit 1260cbcffa608219fc9188a6cbe9c45a300ef8b5 upstream. Make sure to drop the reference taken when looking up the genpool platform device in of_gen_pool_get() before returning the pool. Note that holding a reference to a device does typically not prevent its devres managed resources from being released so there is no point in keeping the reference. Link: https://lkml.kernel.org/r/20250924080207.18006-1-johan@kernel.org Fixes: 9375db07adea ("genalloc: add devres support, allow to find a managed pool by device") Signed-off-by: Johan Hovold Cc: Philipp Zabel Cc: Vladimir Zapolskiy Cc: [3.10+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ebd9834f30b89e584274191ddb0303d509db235e Author: Eric Biggers Date: Sat Aug 9 10:19:39 2025 -0700 KEYS: trusted_tpm1: Compare HMAC values in constant time commit eed0e3d305530066b4fc5370107cff8ef1a0d229 upstream. To prevent timing attacks, HMAC value comparison needs to be constant time. Replace the memcmp() with the correct function, crypto_memneq(). [For the Fixes commit I used the commit that introduced the memcmp(). It predates the introduction of crypto_memneq(), but it was still a bug at the time even though a helper function didn't exist yet.] Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 1bc0d9315ef5296abb2c9fd840336255850ded18 Author: Oleg Nesterov Date: Mon Sep 15 14:09:17 2025 +0200 kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths commit a15f37a40145c986cdf289a4b88390f35efdecc4 upstream. The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable. Link: https://lkml.kernel.org/r/20250915120917.GA27702@redhat.com Fixes: 18c91bb2d872 ("prlimit: do not grab the tasklist_lock") Signed-off-by: Oleg Nesterov Cc: Christian Brauner Cc: Jiri Slaby Cc: Mateusz Guzik Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 05f3c6626a34ccd0f5a8c202457988360e836fc0 Author: Lu Baolu Date: Thu Sep 18 13:02:02 2025 +0800 iommu/vt-d: PRS isn't usable if PDS isn't supported commit 5ef7e24c742038a5d8c626fdc0e3a21834358341 upstream. The specification, Section 7.10, "Software Steps to Drain Page Requests & Responses," requires software to submit an Invalidation Wait Descriptor (inv_wait_dsc) with the Page-request Drain (PD=1) flag set, along with the Invalidation Wait Completion Status Write flag (SW=1). It then waits for the Invalidation Wait Descriptor's completion. However, the PD field in the Invalidation Wait Descriptor is optional, as stated in Section 6.5.2.9, "Invalidation Wait Descriptor": "Page-request Drain (PD): Remapping hardware implementations reporting Page-request draining as not supported (PDS = 0 in ECAP_REG) treat this field as reserved." This implies that if the IOMMU doesn't support the PDS capability, software can't drain page requests and group responses as expected. Do not enable PCI/PRI if the IOMMU doesn't support PDS. Reported-by: Joel Granados Closes: https://lore.kernel.org/r/20250909-jag-pds-v1-1-ad8cba0e494e@kernel.org Fixes: 66ac4db36f4c ("iommu/vt-d: Add page request draining support") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20250915062946.120196-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 2633f79cf29ae75453be12e6be914fd805a0cf36 Author: Sean Nyekjaer Date: Mon Sep 1 09:49:14 2025 +0200 iio: imu: inv_icm42600: Drop redundant pm_runtime reinitialization in resume commit a95a0b4e471a6d8860f40c6ac8f1cad9dde3189a upstream. Remove unnecessary calls to pm_runtime_disable(), pm_runtime_set_active(), and pm_runtime_enable() from the resume path. These operations are not required here and can interfere with proper pm_runtime state handling, especially when resuming from a pm_runtime suspended state. Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer Link: https://patch.msgid.link/20250901-icm42pmreg-v3-2-ef1336246960@geanix.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 04718ab5db770fad3f9ddb0cf2012df587700177 Author: Huacai Chen Date: Mon Jul 21 18:13:43 2025 +0800 init: handle bootloader identifier in kernel parameters commit e416f0ed3c500c05c55fb62ee62662717b1c7f71 upstream. BootLoaders (Grub, LILO, etc) may pass an identifier such as "BOOT_IMAGE= /boot/vmlinuz-x.y.z" to kernel parameters. But these identifiers are not recognized by the kernel itself so will be passed to userspace. However user space init program also don't recognize it. KEXEC/KDUMP (kexec-tools) may also pass an identifier such as "kexec" on some architectures. We cannot change BootLoader's behavior, because this behavior exists for many years, and there are already user space programs search BOOT_IMAGE= in /proc/cmdline to obtain the kernel image locations: https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go (search getBootOptions) https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go (search getKernelReleaseWithBootOption) So the the best way is handle (ignore) it by the kernel itself, which can avoid such boot warnings (if we use something like init=/bin/bash, bootloader identifier can even cause a crash): Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space. [chenhuacai@loongson.cn: use strstarts()] Link: https://lkml.kernel.org/r/20250815090120.1569947-1-chenhuacai@loongson.cn Link: https://lkml.kernel.org/r/20250721101343.3283480-1-chenhuacai@loongson.cn Signed-off-by: Huacai Chen Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7aaddea4461fedb322cb062e17475ce58343f85f Author: Sean Anderson Date: Mon Jul 14 20:28:47 2025 -0400 iio: xilinx-ams: Unmask interrupts after updating alarms commit feb500c7ae7a198db4d2757901bce562feeefa5e upstream. To convert level-triggered alarms into edge-triggered IIO events, alarms are masked when they are triggered. To ensure we catch subsequent alarms, we then periodically poll to see if the alarm is still active. If it isn't, we unmask it. Active but masked alarms are stored in current_masked_alarm. If an active alarm is disabled, it will remain set in current_masked_alarm until ams_unmask_worker clears it. If the alarm is re-enabled before ams_unmask_worker runs, then it will never be cleared from current_masked_alarm. This will prevent the alarm event from being pushed even if the alarm is still active. Fix this by recalculating current_masked_alarm immediately when enabling or disabling alarms. Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver") Signed-off-by: Sean Anderson Reviewed-by: O'Griofa, Conall Tested-by: Erim, Salih Acked-by: Erim, Salih Link: https://patch.msgid.link/20250715002847.2035228-1-sean.anderson@linux.dev Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit de10ea67c8ff6f76644e5a8dcfac88b770800383 Author: Sean Anderson Date: Mon Jul 14 20:30:58 2025 -0400 iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASK commit 1315cc2dbd5034f566e20ddce4d675cb9e6d4ddd upstream. AMS_ALARM_THR_DIRECT_MASK should be bit 0, not bit 1. This would cause hysteresis to be enabled with a lower threshold of -28C. The temperature alarm would never deassert even if the temperature dropped below the upper threshold. Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver") Signed-off-by: Sean Anderson Reviewed-by: O'Griofa, Conall Tested-by: Erim, Salih Acked-by: Erim, Salih Link: https://patch.msgid.link/20250715003058.2035656-1-sean.anderson@linux.dev Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6f69d48954e9bad4de4f1504d38828e65f67943f Author: Michael Hennerich Date: Fri Aug 29 12:25:42 2025 +0100 iio: frequency: adf4350: Fix prescaler usage. commit 33d7ecbf69aa7dd4145e3b77962bcb8759eede3d upstream. The ADF4350/1 features a programmable dual-modulus prescaler of 4/5 or 8/9. When set to 4/5, the maximum RF frequency allowed is 3 GHz. Therefore, when operating the ADF4351 above 3 GHz, this must be set to 8/9. In this context not the RF output frequency is meant - it's the VCO frequency. Therefore move the prescaler selection after we derived the VCO frequency from the desired RF output frequency. This BUG may have caused PLL lock instabilities when operating the VCO at the very high range close to 4.4 GHz. Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20250829-adf4350-fix-v2-1-0bf543ba797d@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 906bb4f98d3a70c8e409aca81cdde82ac6709511 Author: Qianfeng Rong Date: Mon Sep 1 21:57:26 2025 +0800 iio: dac: ad5421: use int type to store negative error codes commit 3379c900320954d768ed9903691fb2520926bbe3 upstream. Change the 'ret' variable in ad5421_update_ctrl() from unsigned int to int, as it needs to store either negative error codes or zero returned by ad5421_write_unlocked(). Fixes: 5691b23489db ("staging:iio:dac: Add AD5421 driver") Signed-off-by: Qianfeng Rong Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20250901135726.17601-3-rongqianfeng@vivo.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b2cbd3b2ccd8c1f778fec4f944c51348e3ff6a19 Author: Qianfeng Rong Date: Mon Sep 1 21:57:25 2025 +0800 iio: dac: ad5360: use int type to store negative error codes commit f9381ece76de999a2065d5b4fdd87fa17883978c upstream. Change the 'ret' variable in ad5360_update_ctrl() from unsigned int to int, as it needs to store either negative error codes or zero returned by ad5360_write_unlocked(). Fixes: a3e2940c24d3 ("staging:iio:dac: Add AD5360 driver") Signed-off-by: Qianfeng Rong Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20250901135726.17601-2-rongqianfeng@vivo.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3fb19f01e527dfba7d7c5b675e4a53e4a7ed5dcc Author: Haoxiang Li Date: Tue Jul 15 17:51:20 2025 +0800 fs/ntfs3: Fix a resource leak bug in wnd_extend() commit d68318471aa2e16222ebf492883e05a2d72b9b17 upstream. Add put_bh() to decrease the refcount of 'bh' after the job is finished, preventing a resource leak. Fixes: 3f3b442b5ad2 ("fs/ntfs3: Add bitmap") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 668dd220950577759f21b6553272c6bfc4f2f88e Author: Thomas Fourier Date: Wed Sep 3 10:34:46 2025 +0200 crypto: atmel - Fix dma_unmap_sg() direction commit f5d643156ef62216955c119216d2f3815bd51cb1 upstream. It seems like everywhere in this file, dd->in_sg is mapped with DMA_TO_DEVICE and dd->out_sg is mapped with DMA_FROM_DEVICE. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Cc: Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e327b96c8379f1f97c26d9f466fea9731825b5b1 Author: Thomas Fourier Date: Wed Sep 10 10:22:31 2025 +0200 crypto: aspeed - Fix dma_unmap_sg() direction commit 838d2d51513e6d2504a678e906823cfd2ecaaa22 upstream. It seems like everywhere in this file, when the request is not bidirectionala, req->src is mapped with DMA_TO_DEVICE and req->dst is mapped with DMA_FROM_DEVICE. Fixes: 62f58b1637b7 ("crypto: aspeed - add HACE crypto driver") Cc: Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0a58d3e77b22b087a57831c87cafd360e144a5bd Author: Rafael J. Wysocki Date: Fri Sep 5 15:52:03 2025 +0200 cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() commit 69e5d50fcf4093fb3f9f41c4f931f12c2ca8c467 upstream. The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later. Fixes: da5c504c7aae ("cpufreq: intel_pstate: Implement QoS supported freq constraints") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Zihuan Zhang Link: https://patch.msgid.link/2255671.irdbgypaU6@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit 7204b0f8f665df9685409d8c8ab26cb4d7e49c3a Author: Simon Schuster Date: Mon Sep 1 15:09:50 2025 +0200 copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64) commit 04ff48239f46e8b493571e260bd0e6c3a6400371 upstream. With the introduction of clone3 in commit 7f192e3cd316 ("fork: add clone3") the effective bit width of clone_flags on all architectures was increased from 32-bit to 64-bit. However, the signature of the copy_* helper functions (e.g., copy_sighand) used by copy_process was not adapted. As such, they truncate the flags on any 32-bit architectures that supports clone3 (arc, arm, csky, m68k, microblaze, mips32, openrisc, parisc32, powerpc32, riscv32, x86-32 and xtensa). For copy_sighand with CLONE_CLEAR_SIGHAND being an actual u64 constant, this triggers an observable bug in kernel selftest clone3_clear_sighand: if (clone_flags & CLONE_CLEAR_SIGHAND) in function copy_sighand within fork.c will always fail given: unsigned long /* == uint32_t */ clone_flags #define CLONE_CLEAR_SIGHAND 0x100000000ULL This commit fixes the bug by always passing clone_flags to copy_sighand via their declared u64 type, invariant of architecture-dependent integer sizes. Fixes: b612e5df4587 ("clone3: add CLONE_CLEAR_SIGHAND") Cc: stable@vger.kernel.org # linux-5.5+ Signed-off-by: Simon Schuster Link: https://lore.kernel.org/20250901-nios2-implement-clone3-v2-1-53fcf5577d57@siemens-energy.com Acked-by: David Hildenbrand Reviewed-by: Lorenzo Stoakes Reviewed-by: Arnd Bergmann Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit c51027fde610dd9268774503d71971683beef54c Author: Adam Xue Date: Fri Sep 5 10:41:18 2025 -0700 bus: mhi: host: Do not use uninitialized 'dev' pointer in mhi_init_irq_setup() commit d0856a6dff57f95cc5d2d74e50880f01697d0cc4 upstream. In mhi_init_irq_setup, the device pointer used for dev_err() was not initialized. Use the pointer from mhi_cntrl instead. Fixes: b0fc0167f254 ("bus: mhi: core: Allow shared IRQ for event rings") Fixes: 3000f85b8f47 ("bus: mhi: core: Add support for basic PM operations") Signed-off-by: Adam Xue [mani: reworded subject/description and CCed stable] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krishna Chaitanya Chundru Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250905174118.38512-1-zxue@semtech.com Signed-off-by: Greg Kroah-Hartman commit d91f6626133698362bba08fbc04bd72c466806d3 Author: Anderson Nascimento Date: Mon Sep 8 09:49:02 2025 -0300 btrfs: avoid potential out-of-bounds in btrfs_encode_fh() commit dff4f9ff5d7f289e4545cc936362e01ed3252742 upstream. The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data. Fixes: be6e8dc0ba84 ("NFS support for btrfs - v3") CC: stable@vger.kernel.org # 3.0+ Signed-off-by: Anderson Nascimento Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c1384179793801acea9a94878a8943b4a7b02cc2 Author: Yu Kuai Date: Wed Sep 10 14:30:45 2025 +0800 blk-crypto: fix missing blktrace bio split events commit 06d712d297649f48ebf1381d19bd24e942813b37 upstream. trace_block_split() is missing, resulting in blktrace inability to catch BIO split events and making it harder to analyze the BIO sequence. Cc: stable@vger.kernel.org Fixes: 488f6682c832 ("block: blk-crypto-fallback for Inline Encryption") Signed-off-by: Yu Kuai Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2df84a62c4f7bdc825ee731f0b4886facaa7ad8e Author: Shuhao Fu Date: Wed Oct 8 00:17:09 2025 +0800 drm/nouveau: fix bad ret code in nouveau_bo_move_prep commit e4bea919584ff292c9156cf7d641a2ab3cbe27b0 upstream. In `nouveau_bo_move_prep`, if `nouveau_mem_map` fails, an error code should be returned. Currently, it returns zero even if vmm addr is not correctly mapped. Cc: stable@vger.kernel.org Reviewed-by: Petr Vorel Signed-off-by: Shuhao Fu Fixes: 9ce523cc3bf2 ("drm/nouveau: separate buffer object backing memory from nvkm structures") Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 5dfb293a1ab736ffdc4ef17b76b3cf2528a12cda Author: Ma Ke Date: Fri Jul 18 17:50:54 2025 +0800 media: lirc: Fix error handling in lirc_register() commit 4f4098c57e139ad972154077fb45c3e3141555dd upstream. When cdev_device_add() failed, calling put_device() to explicitly release dev->lirc_dev. Otherwise, it could cause the fault of the reference count. Found by code review. Cc: stable@vger.kernel.org Fixes: a6ddd4fecbb0 ("media: lirc: remove last remnants of lirc kapi") Signed-off-by: Ma Ke Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e393a23e965b8f3c94c51d864dc17c9dc5164538 Author: Thomas Fourier Date: Wed Jul 16 15:26:30 2025 +0200 media: pci: ivtv: Add missing check after DMA map commit 1069a4fe637d0e3e4c163e3f8df9be306cc299b4 upstream. The DMA map functions can fail and should be tested for errors. If the mapping fails, free blanking_ptr and set it to 0. As 0 is a valid DMA address, use blanking_ptr to test if the DMA address is set. Fixes: 1a0adaf37c30 ("V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoder") Cc: stable@vger.kernel.org Signed-off-by: Thomas Fourier Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a309014f1b1eb1dc2e9ed6c697a564021c58f8e0 Author: Laurent Pinchart Date: Wed Aug 20 17:00:20 2025 +0300 media: mc: Fix MUST_CONNECT handling for pads with no links commit eec81250219a209b863f11d02128ec1dd8e20877 upstream. Commit b3decc5ce7d7 ("media: mc: Expand MUST_CONNECT flag to always require an enabled link") expanded the meaning of the MUST_CONNECT flag to require an enabled link in all cases. To do so, the link exploration code was expanded to cover unconnected pads, in order to reject those that have the MUST_CONNECT flag set. The implementation was however incorrect, ignoring unconnected pads instead of ignoring connected pads. Fix it. Reported-by: Martin Kepplinger-Novaković Closes: https://lore.kernel.org/linux-media/20250205172957.182362-1-martink@posteo.de Reported-by: Maud Spierings Closes: https://lore.kernel.org/linux-media/20250818-imx8_isi-v1-1-e9cfe994c435@gocontroll.com Fixes: b3decc5ce7d7 ("media: mc: Expand MUST_CONNECT flag to always require an enabled link") Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Laurent Pinchart Tested-by: Maud Spierings Tested-by: Martin Kepplinger-Novaković Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 07e73f7db999b8edac7f4e27b7fd0dec9a589120 Author: Qianfeng Rong Date: Wed Aug 27 20:39:10 2025 +0800 media: i2c: mt9v111: fix incorrect type for ret commit bacd713145443dce7764bb2967d30832a95e5ec8 upstream. Change "ret" from unsigned int to int type in mt9v111_calc_frame_rate() to store negative error codes or zero returned by __mt9v111_hw_reset() and other functions. Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. No effect on runtime. Signed-off-by: Qianfeng Rong Fixes: aab7ed1c3927 ("media: i2c: Add driver for Aptina MT9V111") Cc: stable@vger.kernel.org Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 49f672efd82872bddc6cd63a2a1949c1ac87b455 Author: Thomas Fourier Date: Wed Jul 9 13:35:40 2025 +0200 media: cx18: Add missing check after DMA map commit 23b53639a793477326fd57ed103823a8ab63084f upstream. The DMA map functions can fail and should be tested for errors. If the mapping fails, dealloc buffers, and return. Fixes: 1c1e45d17b66 ("V4L/DVB (7786): cx18: new driver for the Conexant CX23418 MPEG encoder chip") Cc: stable@vger.kernel.org Signed-off-by: Thomas Fourier Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 796594990b3ce594ed1c697708aae3fc67af26d9 Author: Johan Hovold Date: Fri Jul 25 09:40:19 2025 +0200 firmware: meson_sm: fix device leak at probe commit 8ece3173f87df03935906d0c612c2aeda9db92ca upstream. Make sure to drop the reference to the secure monitor device taken by of_find_device_by_node() when looking up its driver data on behalf of other drivers (e.g. during probe). Note that holding a reference to the platform device does not prevent its driver data from going away so there is no point in keeping the reference after the helper returns. Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver") Cc: stable@vger.kernel.org # 5.5 Cc: Carlo Caione Signed-off-by: Johan Hovold Acked-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20250725074019.8765-1-johan@kernel.org Signed-off-by: Neil Armstrong Signed-off-by: Greg Kroah-Hartman commit 8c0c3e1bb8599fc1d7cc7c95657e73596e88bee3 Author: Lukas Wunner Date: Thu Sep 4 15:11:09 2025 +0200 xen/manage: Fix suspend error path commit f770c3d858687252f1270265ba152d5c622e793f upstream. The device power management API has the following asymmetry: * dpm_suspend_start() does not clean up on failure (it requires a call to dpm_resume_end()) * dpm_suspend_end() does clean up on failure (it does not require a call to dpm_resume_start()) The asymmetry was introduced by commit d8f3de0d2412 ("Suspend-related patches for 2.6.27") in June 2008: It removed a call to device_resume() from device_suspend() (which was later renamed to dpm_suspend_start()). When Xen began using the device power management API in May 2008 with commit 0e91398f2a5d ("xen: implement save/restore"), the asymmetry did not yet exist. But since it was introduced, a call to dpm_resume_end() is missing in the error path of dpm_suspend_start(). Fix it. Fixes: d8f3de0d2412 ("Suspend-related patches for 2.6.27") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v2.6.27 Reviewed-by: "Rafael J. Wysocki (Intel)" Signed-off-by: Juergen Gross Message-ID: <22453676d1ddcebbe81641bb68ddf587fee7e21e.1756990799.git.lukas@wunner.de> Signed-off-by: Greg Kroah-Hartman commit 1e14e39cfc0a9d1d00716c666e90d46f2a2bdce8 Author: Jason Andryuk Date: Wed Aug 27 20:36:01 2025 -0400 xen/events: Cleanup find_virq() return codes commit 08df2d7dd4ab2db8a172d824cda7872d5eca460a upstream. rc is overwritten by the evtchn_status hypercall in each iteration, so the return value will be whatever the last iteration is. This could incorrectly return success even if the event channel was not found. Change to an explicit -ENOENT for an un-found virq and return 0 on a successful match. Fixes: 62cc5fc7b2e0 ("xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports") Cc: stable@vger.kernel.org Signed-off-by: Jason Andryuk Reviewed-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20250828003604.8949-2-jason.andryuk@amd.com> Signed-off-by: Greg Kroah-Hartman commit 0e46a2c79313e95a0c7e93fcbad0d425d8d20ab6 Author: Michael Riesch Date: Wed Sep 3 19:04:50 2025 +0200 dt-bindings: phy: rockchip-inno-csi-dphy: make power-domains non-required commit c254815b02673cc77a84103c4c0d6197bd90c0ef upstream. There are variants of the Rockchip Innosilicon CSI DPHY (e.g., the RK3568 variant) that are powered on by default as they are part of the ALIVE power domain. Remove 'power-domains' from the required properties in order to avoid false positives. Fixes: 22c8e0a69b7f ("dt-bindings: phy: add compatible for rk356x to rockchip-inno-csi-dphy") Cc: stable@kernel.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Michael Riesch Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-2-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit dbeeee44a39174e2237370bc7e81190a61671b5f Author: Rafael J. Wysocki Date: Mon Aug 11 17:03:11 2025 +0200 cpuidle: governors: menu: Avoid using invalid recent intervals data commit fa3fa55de0d6177fdcaf6fc254f13cc8f33c3eed upstream. Marc has reported that commit 85975daeaa4d ("cpuidle: menu: Avoid discarding useful information") caused the number of wakeup interrupts to increase on an idle system [1], which was not expected to happen after merely allowing shallower idle states to be selected by the governor in some cases. However, on the system in question, all of the idle states deeper than WFI are rejected by the driver due to a firmware issue [2]. This causes the governor to only consider the recent interval duriation data corresponding to attempts to enter WFI that are successful and the recent invervals table is filled with values lower than the scheduler tick period. Consequently, the governor predicts an idle duration below the scheduler tick period length and avoids stopping the tick more often which leads to the observed symptom. Address it by modifying the governor to update the recent intervals table also when entering the previously selected idle state fails, so it knows that the short idle intervals might have been the minority had the selected idle states been actually entered every time. Fixes: 85975daeaa4d ("cpuidle: menu: Avoid discarding useful information") Link: https://lore.kernel.org/linux-pm/86o6sv6n94.wl-maz@kernel.org/ [1] Link: https://lore.kernel.org/linux-pm/7ffcb716-9a1b-48c2-aaa4-469d0df7c792@arm.com/ [2] Signed-off-by: Rafael J. Wysocki Tested-by: Christian Loehle Tested-by: Marc Zyngier Reviewed-by: Christian Loehle Link: https://patch.msgid.link/2793874.mvXUDI8C0e@rafael.j.wysocki Cc: Sergey Senozhatsky Signed-off-by: Greg Kroah-Hartman commit 1a35536459b38324da7ab25abfae313989da1098 Author: Miaoqian Lin Date: Tue Sep 2 15:59:43 2025 +0800 ARM: OMAP2+: pm33xx-core: ix device node reference leaks in amx3_idle_init commit 74139a64e8cedb6d971c78d5d17384efeced1725 upstream. Add missing of_node_put() calls to release device node references obtained via of_parse_phandle(). Fixes: 06ee7a950b6a ("ARM: OMAP2+: pm33xx-core: Add cpuidle_ops for am335x/am437x") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20250902075943.2408832-1-linmq006@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 569e08cecc97c600f98f627c9d1ed33d73b5b5a0 Author: Vibhore Vardhan Date: Wed Sep 3 11:55:12 2025 +0530 arm64: dts: ti: k3-am62a-main: Fix main padcfg length commit 4c4e48afb6d85c1a8f9fdbae1fdf17ceef4a6f5b upstream. The main pad configuration register region starts with the register MAIN_PADCFG_CTRL_MMR_CFG0_PADCONFIG0 with address 0x000f4000 and ends with the MAIN_PADCFG_CTRL_MMR_CFG0_PADCONFIG150 register with address 0x000f4258, as a result of which, total size of the region is 0x25c instead of 0x2ac. Reference Docs TRM (AM62A) - https://www.ti.com/lit/ug/spruj16b/spruj16b.pdf TRM (AM62D) - https://www.ti.com/lit/ug/sprujd4/sprujd4.pdf Fixes: 5fc6b1b62639c ("arm64: dts: ti: Introduce AM62A7 family of SoCs") Cc: stable@vger.kernel.org Signed-off-by: Vibhore Vardhan Signed-off-by: Paresh Bhagat Reviewed-by: Siddharth Vadapalli Link: https://patch.msgid.link/20250903062513.813925-2-p-bhagat@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Greg Kroah-Hartman commit 3b94ab63fd0e994efef4433a00afaef3b30b3afa Author: Stephan Gerhold Date: Thu Aug 21 10:15:09 2025 +0200 arm64: dts: qcom: sdm845: Fix slimbam num-channels/ees commit 316294bb6695a43a9181973ecd4e6fb3e576a9f7 upstream. Reading the hardware registers of the &slimbam on RB3 reveals that the BAM supports only 23 pipes (channels) and supports 4 EEs instead of 2. This hasn't caused problems so far since nothing is using the extra channels, but attempting to use them would lead to crashes. The bam_dma driver might warn in the future if the num-channels in the DT are wrong, so correct the properties in the DT to avoid future regressions. Cc: stable@vger.kernel.org Fixes: 27ca1de07dc3 ("arm64: dts: qcom: sdm845: add slimbus nodes") Signed-off-by: Stephan Gerhold Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250821-sdm845-slimbam-channels-v1-1-498f7d46b9ee@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit c862a8f014a1e77dc6ca99b073d163b75202525f Author: Stephan Gerhold Date: Mon Sep 15 15:28:30 2025 +0200 arm64: dts: qcom: msm8916: Add missing MDSS reset commit 99b78773c2ae55dcc01025f94eae8ce9700ae985 upstream. On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader already initializes the display to show the boot splash screen. In this situation, MDSS is already configured and left running when starting Linux. To avoid side effects from the bootloader configuration, the MDSS reset can be specified in the device tree to start again with a clean hardware state. The reset for MDSS is currently missing in msm8916.dtsi, which causes errors when the MDSS driver tries to re-initialize the registers: dsi_err_worker: status=6 dsi_err_worker: status=6 dsi_err_worker: status=6 ... It turns out that we have always indirectly worked around this by building the MDSS driver as a module. Before v6.17, the power domain was temporarily turned off until the module was loaded, long enough to clear the register contents. In v6.17, power domains are not turned off during boot until sync_state() happens, so this is no longer working. Even before v6.17 this resulted in broken behavior, but notably only when the MDSS driver was built-in instead of a module. Cc: stable@vger.kernel.org Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Stephan Gerhold Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-1-a5c705df0c45@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 234d0f84d259c3f037ca2604be3d8bb7f89c72b1 Author: Amir Mohammad Jahangirzad Date: Tue Sep 23 05:01:13 2025 +0330 ACPI: debug: fix signedness issues in read/write helpers commit 496f9372eae14775e0524e83e952814691fe850a upstream. In the ACPI debugger interface, the helper functions for read and write operations use "int" as the length parameter data type. When a large "size_t count" is passed from the file operations, this cast to "int" results in truncation and a negative value due to signed integer representation. Logically, this negative number propagates to the min() calculation, where it is selected over the positive buffer space value, leading to unexpected behavior. Subsequently, when this negative value is used in copy_to_user() or copy_from_user(), it is interpreted as a large positive value due to the unsigned nature of the size parameter in these functions, causing the copy operations to attempt handling sizes far beyond the intended buffer limits. Address the issue by: - Changing the length parameters in acpi_aml_read_user() and acpi_aml_write_user() from "int" to "size_t", aligning with the expected unsigned size semantics. - Updating return types and local variables in acpi_aml_read() and acpi_aml_write() to "ssize_t" for consistency with kernel file operation conventions. - Using "size_t" for the "n" variable to ensure calculations remain unsigned. - Using min_t() for circ_count_to_end() and circ_space_to_end() to ensure type-safe comparisons and prevent integer overflow. Signed-off-by: Amir Mohammad Jahangirzad Link: https://patch.msgid.link/20250923013113.20615-1-a.jahangirzad@gmail.com [ rjw: Changelog tweaks, local variable definitions ordering adjustments ] Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities") Cc: 4.5+ # 4.5+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cf4375a4a9c6cd1062bd00ac0790b4b2cc5f3f80 Author: Daniel Tang Date: Thu Aug 28 01:38:14 2025 -0400 ACPI: TAD: Add missing sysfs_remove_group() for ACPI_TAD_RT commit 4aac453deca0d9c61df18d968f8864c3ae7d3d8d upstream. Previously, after `rmmod acpi_tad`, `modprobe acpi_tad` would fail with this dmesg: sysfs: cannot create duplicate filename '/devices/platform/ACPI000E:00/time' Call Trace: dump_stack_lvl+0x6c/0x90 dump_stack+0x10/0x20 sysfs_warn_dup+0x8b/0xa0 sysfs_add_file_mode_ns+0x122/0x130 internal_create_group+0x1dd/0x4c0 sysfs_create_group+0x13/0x20 acpi_tad_probe+0x147/0x1f0 [acpi_tad] platform_probe+0x42/0xb0 acpi-tad ACPI000E:00: probe with driver acpi-tad failed with error -17 Fixes: 3230b2b3c1ab ("ACPI: TAD: Add low-level support for real time capability") Signed-off-by: Daniel Tang Reviewed-by: Mika Westerberg Link: https://patch.msgid.link/2881298.hMirdbgypa@daniel-desktop3 Cc: 5.2+ # 5.2+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 976b3bbdea3a5ae13086b56660562721bcf4396b Author: Rafael J. Wysocki Date: Mon Sep 15 20:21:33 2025 +0200 ACPI: property: Fix buffer properties extraction for subnodes commit d0759b10989c5c5aae3d455458c9fc4e8cc694f7 upstream. The ACPI handle passed to acpi_extract_properties() as the first argument represents the ACPI namespace scope in which to look for objects returning buffers associated with buffer properties. For _DSD objects located immediately under ACPI devices, this handle is the same as the handle of the device object holding the _DSD, but for data-only subnodes it is not so. First of all, data-only subnodes are represented by objects that cannot hold other objects in their scopes (like control methods). Therefore a data-only subnode handle cannot be used for completing relative pathname segments, so the current code in in acpi_nondev_subnode_extract() passing a data-only subnode handle to acpi_extract_properties() is invalid. Moreover, a data-only subnode of device A may be represented by an object located in the scope of device B (which kind of makes sense, for instance, if A is a B's child). In that case, the scope in question would be the one of device B. In other words, the scope mentioned above is the same as the scope used for subnode object lookup in acpi_nondev_subnode_extract(). Accordingly, rearrange that function to use the same scope for the extraction of properties and subnode object lookup. Fixes: 103e10c69c61 ("ACPI: property: Add support for parsing buffer property UUID") Cc: 6.0+ # 6.0+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Sakari Ailus Tested-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 743a620c661994c7f0938e6dd32fb0883fb1e0ea Author: KaFai Wan Date: Wed Oct 8 18:26:26 2025 +0800 bpf: Avoid RCU context warning when unpinning htab with internal structs [ Upstream commit 4f375ade6aa9f37fd72d7a78682f639772089eed ] When unpinning a BPF hash table (htab or htab_lru) that contains internal structures (timer, workqueue, or task_work) in its values, a BUG warning is triggered: BUG: sleeping function called from invalid context at kernel/bpf/hashtab.c:244 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0 ... The issue arises from the interaction between BPF object unpinning and RCU callback mechanisms: 1. BPF object unpinning uses ->free_inode() which schedules cleanup via call_rcu(), deferring the actual freeing to an RCU callback that executes within the RCU_SOFTIRQ context. 2. During cleanup of hash tables containing internal structures, htab_map_free_internal_structs() is invoked, which includes cond_resched() or cond_resched_rcu() calls to yield the CPU during potentially long operations. However, cond_resched() or cond_resched_rcu() cannot be safely called from atomic RCU softirq context, leading to the BUG warning when attempting to reschedule. Fix this by changing from ->free_inode() to ->destroy_inode() and rename bpf_free_inode() to bpf_destroy_inode() for BPF objects (prog, map, link). This allows direct inode freeing without RCU callback scheduling, avoiding the invalid context warning. Reported-by: Le Chen Closes: https://lore.kernel.org/all/1444123482.1827743.1750996347470.JavaMail.zimbra@sjtu.edu.cn/ Fixes: 68134668c17f ("bpf: Add map side support for bpf timers.") Suggested-by: Alexei Starovoitov Signed-off-by: KaFai Wan Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20251008102628.808045-2-kafai.wan@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c77c92403781b95c779423ef59909af744f37189 Author: Bartosz Golaszewski Date: Wed Sep 24 16:51:29 2025 +0200 gpio: wcd934x: mark the GPIO controller as sleeping [ Upstream commit b5f8aa8d4bde0cf3e4595af5a536da337e5f1c78 ] The slimbus regmap passed to the GPIO driver down from MFD does not use fast_io. This means a mutex is used for locking and thus this GPIO chip must not be used in atomic context. Change the can_sleep switch in struct gpio_chip to true. Fixes: 59c324683400 ("gpio: wcd934x: Add support to wcd934x gpio controller") Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit bce16a4257ffdf7ffcdbef6a6014724286381df6 Author: Andy Shevchenko Date: Fri Jan 13 20:26:18 2023 +0200 gpio: wcd934x: Remove duplicate assignment of of_gpio_n_cells [ Upstream commit a060dc6620c13435b78e92cd2ebdbb6d11af237a ] The of_gpio_n_cells default is 2 when ->of_xlate() callback is not defined. No need to assign it explicitly in the driver. Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Stable-dep-of: b5f8aa8d4bde ("gpio: wcd934x: mark the GPIO controller as sleeping") Signed-off-by: Sasha Levin commit 441ab7ad7548cea59f2f3ba3b10d6e4ed0a7998e Author: Gunnar Kudrjavets Date: Thu Sep 18 18:49:40 2025 +0300 tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single [ Upstream commit 8a81236f2cb0882c7ea6c621ce357f7f3f601fe5 ] The tpm_tis_write8() call specifies arguments in wrong order. Should be (data, addr, value) not (data, value, addr). The initial correct order was changed during the major refactoring when the code was split. Fixes: 41a5e1cf1fe1 ("tpm/tpm_tis: Split tpm_tis driver into a core and TCG TIS compliant phy") Signed-off-by: Gunnar Kudrjavets Reviewed-by: Justinien Bouron Reviewed-by: Jarkko Sakkinen Reviewed-by: Paul Menzel Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 248ff2797ff52a8cbf86507f9583437443bf7685 Author: Herbert Xu Date: Wed Oct 8 15:54:20 2025 +0800 crypto: essiv - Check ssize for decryption and in-place encryption [ Upstream commit 6bb73db6948c2de23e407fe1b7ef94bf02b7529f ] Move the ssize check to the start in essiv_aead_crypt so that it's also checked for decryption and in-place encryption. Reported-by: Muhammad Alifa Ramdhan Fixes: be1eb7f78aa8 ("crypto: essiv - create wrapper template for ESSIV generation") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7043c73a6429326a0f7e60db0954fa941597e8c6 Author: Eric Woudstra Date: Tue Oct 7 10:15:01 2025 +0200 bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu() [ Upstream commit bbf0c98b3ad9edaea1f982de6c199cc11d3b7705 ] net/bridge/br_private.h:1627 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 7 locks held by socat/410: #0: ffff88800d7a9c90 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_stream_connect+0x43/0xa0 #1: ffffffff9a779900 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x62/0x1830 [..] #6: ffffffff9a779900 (rcu_read_lock){....}-{1:3}, at: nf_hook.constprop.0+0x8a/0x440 Call Trace: lockdep_rcu_suspicious.cold+0x4f/0xb1 br_vlan_fill_forward_path_pvid+0x32c/0x410 [bridge] br_fill_forward_path+0x7a/0x4d0 [bridge] Use to correct helper, non _rcu variant requires RTNL mutex. Fixes: bcf2766b1377 ("net: bridge: resolve forwarding path for VLAN tag actions in bridge devices") Signed-off-by: Eric Woudstra Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 8f99b75869183ae1a6e3101a1a21ee5a4fa74e0d Author: Timur Kristóf Date: Thu Sep 25 20:45:24 2025 +0200 drm/amd/display: Properly disable scaling on DCE6 [ Upstream commit a7dc87f3448bea5ebe054f14e861074b9c289c65 ] SCL_SCALER_ENABLE can be used to enable/disable the scaler on DCE6. Program it to 0 when scaling isn't used, 1 when used. Additionally, clear some other registers when scaling is disabled and program the SCL_UPDATE register as recommended. This fixes visible glitches for users whose BIOS sets up a mode with scaling at boot, which DC was unable to clean up. Fixes: b70aaf5586f2 ("drm/amd/display: dce_transform: add DCE6 specific macros,functions") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ffb11feb89ab753759daa27d8c518ec8397384bd Author: Timur Kristóf Date: Thu Sep 25 20:45:23 2025 +0200 drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6 [ Upstream commit c0aa7cf49dd6cb302fe28e7183992b772cb7420c ] Previously, the code would set a bit field which didn't exist on DCE6 so it would be effectively a no-op. Fixes: b70aaf5586f2 ("drm/amd/display: dce_transform: add DCE6 specific macros,functions") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 040db9f5e7c75264acff81543644c46cc60eef09 Author: Timur Kristóf Date: Thu Sep 25 20:45:22 2025 +0200 drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs [ Upstream commit d60f9c45d1bff7e20ecd57492ef7a5e33c94a37c ] Without these, it's impossible to program these registers. Fixes: 102b2f587ac8 ("drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init (v2)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cac8204403db9dd2db63723aef5a8b70653f8faf Author: Alex Deucher Date: Thu Sep 25 20:45:21 2025 +0200 drm/amdgpu: Add additional DCE6 SCL registers [ Upstream commit 507296328b36ffd00ec1f4fde5b8acafb7222ec7 ] Fixes: 102b2f587ac8 ("drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init (v2)") Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2e67c2037382abb56497bb9d7b7e10be04eb5598 Author: Daniel Borkmann Date: Fri Oct 3 09:34:18 2025 +0200 bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} [ Upstream commit 23f3770e1a53e6c7a553135011f547209e141e72 ] Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first. Fixes: b4ab31414970 ("bpf: Add redirect_neigh helper as redirect drop-in") Reported-by: Yusuke Suzuki Reported-by: Julian Wiedmann Signed-off-by: Daniel Borkmann Cc: Martin KaFai Lau Cc: Jakub Kicinski Cc: Jordan Rife Reviewed-by: Simon Horman Reviewed-by: Jordan Rife Reviewed-by: Jakub Kicinski Reviewed-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20251003073418.291171-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 429eaced61cf759e727d661ecca68ebd5ffcc5ed Author: Harini T Date: Mon Sep 29 13:07:21 2025 +0530 mailbox: zynqmp-ipi: Remove dev.parent check in zynqmp_ipi_free_mboxes [ Upstream commit 019e3f4550fc7d319a7fd03eff487255f8e8aecd ] The ipi_mbox->dev.parent check is unreliable proxy for registration status as it fails to protect against probe failures that occur after the parent is assigned but before device_register() completes. device_is_registered() is the canonical and robust method to verify the registration status. Remove ipi_mbox->dev.parent check in zynqmp_ipi_free_mboxes(). Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Harini T Reviewed-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2e75e32721bb65f18eb1a2014215f4a4f4aa05f2 Author: Harini T Date: Mon Sep 29 13:07:20 2025 +0530 mailbox: zynqmp-ipi: Remove redundant mbox_controller_unregister() call [ Upstream commit 341867f730d3d3bb54491ee64e8b1a0c446656e7 ] The controller is registered using the device-managed function 'devm_mbox_controller_register()'. As documented in mailbox.c, this ensures the devres framework automatically calls mbox_controller_unregister() when device_unregister() is invoked, making the explicit call unnecessary. Remove redundant mbox_controller_unregister() call as device_unregister() handles controller cleanup. Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Harini T Reviewed-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 6263c38c0d6f58898b5ddfb00d41c9df5906a3be Author: Leo Yan Date: Mon Oct 6 17:21:23 2025 +0100 tools build: Align warning options with perf [ Upstream commit 53d067feb8c4f16d1f24ce3f4df4450bb18c555f ] The feature test programs are built without enabling '-Wall -Werror' options. As a result, a feature may appear to be available, but later building in perf can fail with stricter checks. Make the feature test program use the same warning options as perf. Fixes: 1925459b4d92 ("tools build: Fix feature Makefile issues with 'O='") Signed-off-by: Leo Yan Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20251006-perf_build_android_ndk-v3-1-4305590795b2@arm.com Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alexandre Ghiti Cc: Nick Desaulniers Cc: Justin Stitt Cc: Bill Wendling Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: Nathan Chancellor Cc: James Clark Cc: linux-riscv@lists.infradead.org Cc: llvm@lists.linux.dev Cc: Paul Walmsley Cc: linux-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 95c25d7a419db4fdbfb5cb0d69125fa8cd003253 Author: Erick Karanja Date: Thu Oct 2 20:46:17 2025 +0300 net: fsl_pq_mdio: Fix device node reference leak in fsl_pq_mdio_probe [ Upstream commit 521405cb54cd2812bbb6dedd5afc14bca1e7e98a ] Add missing of_node_put call to release device node tbi obtained via for_each_child_of_node. Fixes: afae5ad78b342 ("net/fsl_pq_mdio: streamline probing of MDIO nodes") Signed-off-by: Erick Karanja Link: https://patch.msgid.link/20251002174617.960521-1-karanja99erick@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 643a94b0cf767325e953591c212be2eb826b9d7f Author: Kuniyuki Iwashima Date: Wed Oct 1 23:37:54 2025 +0000 tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). [ Upstream commit 2e7cbbbe3d61c63606994b7ff73c72537afe2e1c ] syzbot reported the splat below in tcp_conn_request(). [0] If a listener is close()d while a TFO socket is being processed in tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk and calls inet_child_forget(), which calls tcp_disconnect() for the TFO socket. After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk. Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the drop_and_free label causes the refcount underflow for the listener and double-free of the reqsk. Let's remove reqsk_fastopen_remove() in tcp_conn_request(). Note that other callers make sure tp->fastopen_rsk is not NULL. [0]: refcount_t: underflow; use-after-free. WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:refcount_warn_saturate (lib/refcount.c:28) Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6 RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246 RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900 RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280 RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280 R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100 R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8 FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0 Call Trace: tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480) Fixes: 45c8a6cc2bcd ("tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().") Reported-by: syzkaller Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251001233755.1340927-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 025419f4e216a3ae0d0cec622262e98e8078c447 Author: Alexandr Sapozhnikov Date: Thu Oct 2 12:14:47 2025 +0300 net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() [ Upstream commit 2f3119686ef50319490ccaec81a575973da98815 ] If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function. Signed-off-by: Alexandr Sapozhnikov Acked-by: Xin Long Fixes: 30f6ebf65bc4 ("sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT") Link: https://patch.msgid.link/20251002091448.11-1-alsp705@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8ae6247dc66d7a49475ac55006b500134e8822d9 Author: Ian Forbes Date: Fri Sep 26 14:54:26 2025 -0500 drm/vmwgfx: Fix copy-paste typo in validation [ Upstream commit 228c5d44dffe8c293cd2d2f0e7ea45e64565b1c4 ] 'entry' should be 'val' which is the loop iterator. Fixes: 9e931f2e0970 ("drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.") Signed-off-by: Ian Forbes Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://lore.kernel.org/r/20250926195427.1405237-2-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit 9a8eaca539708ca532747f606d231f70e684e8ca Author: Ian Forbes Date: Fri Sep 26 14:54:25 2025 -0500 drm/vmwgfx: Fix Use-after-free in validation [ Upstream commit dfe1323ab3c8a4dd5625ebfdba44dc47df84512a ] Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely. Fixes: 64ad2abfe9a6 ("drm/vmwgfx: Adapt validation code for reference-free lookups") Reported-by: Kuzey Arda Bulut Signed-off-by: Ian Forbes Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://lore.kernel.org/r/20250926195427.1405237-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit f0b8a49cc5eb71826da0ecfe73fe2cc23b7ef655 Author: Dan Carpenter Date: Tue Sep 30 15:25:01 2025 +0300 net/mlx4: prevent potential use after free in mlx4_en_do_uc_filter() [ Upstream commit 4f0d91ba72811fd5dd577bcdccd7fed649aae62c ] Print "entry->mac" before freeing "entry". The "entry" pointer is freed with kfree_rcu() so it's unlikely that we would trigger this in real life, but it's safer to re-order it. Fixes: cc5387f7346a ("net/mlx4_en: Add unicast MAC filtering") Signed-off-by: Dan Carpenter Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/aNvMHX4g8RksFFvV@stanley.mountain Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b322287100ff5f2ff7729b38680f88216bdcbbe6 Author: Huacai Chen Date: Thu Oct 2 22:38:57 2025 +0800 LoongArch: Init acpi_gbl_use_global_lock to false [ Upstream commit 98662be7ef20d2b88b598f72e7ce9b6ac26a40f9 ] Init acpi_gbl_use_global_lock to false, in order to void error messages during boot phase: ACPI Error: Could not enable GlobalLock event (20240827/evxfevnt-182) ACPI Error: No response from Global Lock hardware, disabling lock (20240827/evglock-59) Fixes: 628c3bb40e9a8cefc0a6 ("LoongArch: Add boot and setup routines") Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit affdc8880b3cfa753d4936b440eaca860242da20 Author: Tiezhu Yang Date: Mon Jun 3 15:45:53 2024 +0800 LoongArch: Remove CONFIG_ACPI_TABLE_UPGRADE in platform_init() [ Upstream commit 6c3ca6654a74dd396bc477839ba8d9792eced441 ] Both acpi_table_upgrade() and acpi_boot_table_init() are defined as empty functions under !CONFIG_ACPI_TABLE_UPGRADE and !CONFIG_ACPI in include/linux/acpi.h, there are no implicit declaration errors with various configs. #ifdef CONFIG_ACPI_TABLE_UPGRADE void acpi_table_upgrade(void); #else static inline void acpi_table_upgrade(void) { } #endif #ifdef CONFIG_ACPI ... void acpi_boot_table_init (void); ... #else /* !CONFIG_ACPI */ ... static inline void acpi_boot_table_init(void) { } ... #endif /* !CONFIG_ACPI */ As Huacai suggested, CONFIG_ACPI_TABLE_UPGRADE is ugly and not necessary here, just remove it. At the same time, just keep CONFIG_ACPI to prevent potential build errors in future, and give a signal to indicate the code is ACPI-specific. For the same reason, we also put acpi_table_upgrade() under CONFIG_ACPI. Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Stable-dep-of: 98662be7ef20 ("LoongArch: Init acpi_gbl_use_global_lock to false") Signed-off-by: Sasha Levin commit c2c35cb2a31844f84f21ab364b38b4309d756d42 Author: Duoming Zhou Date: Sat Sep 20 21:42:01 2025 +0800 scsi: mvsas: Fix use-after-free bugs in mvs_work_queue [ Upstream commit 60cd16a3b7439ccb699d0bf533799eeb894fd217 ] During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis. Fixes: 20b09c2992fe ("[SCSI] mvsas: add support for 94xx; layout change; bug fixes") Signed-off-by: Duoming Zhou Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c56fecded1b06905a4a995437167ca1568d64421 Author: John Garry Date: Tue Oct 18 19:16:03 2022 +0800 scsi: mvsas: Use sas_task_find_rq() for tagging [ Upstream commit 2acf97f199f9eba8321390325519e9b6bff60108 ] The request associated with a SCSI command coming from the block layer has a unique tag, so use that when possible for getting a slot. Unfortunately we don't support reserved commands in the SCSI midlayer yet. As such, SMP tasks - as an example - will not have a request associated, so in the interim continue to manage those tags for that type of sas_task internally. We reserve an arbitrary 4 tags for these internal tags. Indeed, we already decrement MVS_RSVD_SLOTS by 2 for the shost can_queue when flag MVF_FLAG_SOC is set. This change was made in commit 20b09c2992fe ("[SCSI] mvsas: add support for 94xx; layout change; bug fixes"), but what those 2 slots are used for is not obvious. Also make the tag management functions static, where possible. Signed-off-by: John Garry Link: https://lore.kernel.org/r/1666091763-11023-8-git-send-email-john.garry@huawei.com Signed-off-by: Martin K. Petersen Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue") Signed-off-by: Sasha Levin commit 663384f5226ef56bf1d4b758894e74177459b775 Author: John Garry Date: Tue Oct 18 19:16:02 2022 +0800 scsi: mvsas: Delete mvs_tag_init() [ Upstream commit ffc9f9bf3f14876d019f67ef17d41138802529a8 ] All mvs_tag_init() does is zero the tag bitmap, but this is already done with the kzalloc() call to alloc the tags, so delete this unneeded function. Signed-off-by: John Garry Link: https://lore.kernel.org/r/1666091763-11023-7-git-send-email-john.garry@huawei.com Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue") Signed-off-by: Sasha Levin commit 5b4d15d64554f69bdc3dd061f94b7df2f92861c3 Author: John Garry Date: Tue Oct 18 19:15:57 2022 +0800 scsi: libsas: Add sas_task_find_rq() [ Upstream commit a9ee3f840646e2ec419c734e592ffe997195435e ] blk-mq already provides a unique tag per request. Some libsas LLDDs - like hisi_sas - already use this tag as the unique per-I/O HW tag. Add a common function to provide the request associated with a sas_task for all libsas LLDDs. Signed-off-by: John Garry Link: https://lore.kernel.org/r/1666091763-11023-2-git-send-email-john.garry@huawei.com Reviewed-by: Jack Wang Reviewed-by: Jason Yan Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue") Signed-off-by: Sasha Levin commit d2491289051a5927e455656328d830959b3723e4 Author: Aaron Kling Date: Thu Aug 28 21:48:12 2025 -0500 cpufreq: tegra186: Set target frequency for all cpus in policy [ Upstream commit 0b1bb980fd7cae126ee3d59f817068a13e321b07 ] The original commit set all cores in a cluster to a shared policy, but did not update set_target to apply a frequency change to all cores for the policy. This caused most cores to remain stuck at their boot frequency. Fixes: be4ae8c19492 ("cpufreq: tegra186: Share policy per cluster") Signed-off-by: Aaron Kling Reviewed-by: Mikko Perttunen Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 635c125cdccc4edb1fce2560caed6e7496218c01 Author: Fedor Pchelkin Date: Sat Apr 26 15:54:28 2025 +0300 clk: tegra: do not overallocate memory for bpmp clocks [ Upstream commit 49ef6491106209c595476fc122c3922dfd03253f ] struct tegra_bpmp::clocks is a pointer to a dynamically allocated array of pointers to 'struct tegra_bpmp_clk'. But the size of the allocated area is calculated like it is an array containing actual 'struct tegra_bpmp_clk' objects - it's not true, there are just pointers. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 2db12b15c6f3 ("clk: tegra: Register clocks from root to leaf") Signed-off-by: Fedor Pchelkin Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5cb1c7600e333eb91b1749e5b7332a823104ba04 Author: Alok Tiwari Date: Sun Jul 6 13:11:55 2025 -0700 clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver [ Upstream commit 1624dead9a4d288a594fdf19735ebfe4bb567cb8 ] The conditional check for the PLL0 multiplier 'm' used a logical AND instead of OR, making the range check ineffective. This patch replaces && with || to correctly reject invalid values of 'm' that are either less than or equal to 0 or greater than LPC18XX_PLL0_MSEL_MAX. This ensures proper bounds checking during clk rate setting and rounding. Fixes: b04e0b8fd544 ("clk: add lpc18xx cgu clk driver") Signed-off-by: Alok Tiwari [sboyd@kernel.org: 'm' is unsigned so remove < condition] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit fcc494ce4346d8a515f08c32c7f30f0c9e802eca Author: Brian Masney Date: Mon Aug 11 11:18:29 2025 -0400 clk: nxp: lpc18xx-cgu: convert from round_rate() to determine_rate() [ Upstream commit b46a3d323a5b7942e65025254c13801d0f475f02 ] The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. Signed-off-by: Brian Masney Stable-dep-of: 1624dead9a4d ("clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver") Signed-off-by: Sasha Levin commit 34c7e1d11bb1d53b69877cc481ce992792633faf Author: Chen-Yu Tsai Date: Mon Aug 25 23:09:31 2025 +0800 clk: mediatek: clk-mux: Do not pass flags to clk_mux_determine_rate_flags() [ Upstream commit 5e121370a7ad3414c7f3a77002e2b18abe5c6fe1 ] The `flags` in |struct mtk_mux| are core clk flags, not mux clk flags. Passing one to the other is wrong. Since there aren't any actual users adding CLK_MUX_* flags, just drop it for now. Fixes: b05ea3314390 ("clk: mediatek: clk-mux: Add .determine_rate() callback") Signed-off-by: Chen-Yu Tsai Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4b105cf2a13bd4520a0c89f7c20cc08be1fb7b8d Author: AngeloGioacchino Del Regno Date: Thu Jul 24 10:38:28 2025 +0200 clk: mediatek: mt8195-infra_ao: Fix parent for infra_ao_hdmi_26m [ Upstream commit 6c4c26b624790098988c1034541087e3e5ed5bed ] The infrastructure gate for the HDMI specific crystal needs the top_hdmi_xtal clock to be configured in order to ungate the 26m clock to the HDMI IP, and it wouldn't work without. Reparent the infra_ao_hdmi_26m clock to top_hdmi_xtal to fix that. Fixes: e2edf59dec0b ("clk: mediatek: Add MT8195 infrastructure clock support") Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2c15e7ba53cafc2f1a1718069717a18a67d161f4 Author: Ian Rogers Date: Thu Sep 18 15:22:00 2025 -0700 perf test: Don't leak workload gopipe in PERF_RECORD_* [ Upstream commit 48918cacefd226af44373e914e63304927c0e7dc ] The test starts a workload and then opens events. If the events fail to open, for example because of perf_event_paranoid, the gopipe of the workload is leaked and the file descriptor leak check fails when the test exits. To avoid this cancel the workload when opening the events fails. Before: ``` $ perf test -vv 7 7: PERF_RECORD_* events & perf_sample fields: --- start --- test child forked, pid 1189568 Using CPUID GenuineIntel-6-B7-1 ------------------------------------------------------------ perf_event_attr: type 0 (PERF_TYPE_HARDWARE) config 0xa00000000 (cpu_atom/PERF_COUNT_HW_CPU_CYCLES/) disabled 1 ------------------------------------------------------------ sys_perf_event_open: pid 0 cpu -1 group_fd -1 flags 0x8 sys_perf_event_open failed, error -13 ------------------------------------------------------------ perf_event_attr: type 0 (PERF_TYPE_HARDWARE) config 0xa00000000 (cpu_atom/PERF_COUNT_HW_CPU_CYCLES/) disabled 1 exclude_kernel 1 ------------------------------------------------------------ sys_perf_event_open: pid 0 cpu -1 group_fd -1 flags 0x8 = 3 ------------------------------------------------------------ perf_event_attr: type 0 (PERF_TYPE_HARDWARE) config 0x400000000 (cpu_core/PERF_COUNT_HW_CPU_CYCLES/) disabled 1 ------------------------------------------------------------ sys_perf_event_open: pid 0 cpu -1 group_fd -1 flags 0x8 sys_perf_event_open failed, error -13 ------------------------------------------------------------ perf_event_attr: type 0 (PERF_TYPE_HARDWARE) config 0x400000000 (cpu_core/PERF_COUNT_HW_CPU_CYCLES/) disabled 1 exclude_kernel 1 ------------------------------------------------------------ sys_perf_event_open: pid 0 cpu -1 group_fd -1 flags 0x8 = 3 Attempt to add: software/cpu-clock/ ..after resolving event: software/config=0/ cpu-clock -> software/cpu-clock/ ------------------------------------------------------------ perf_event_attr: type 1 (PERF_TYPE_SOFTWARE) size 136 config 0x9 (PERF_COUNT_SW_DUMMY) sample_type IP|TID|TIME|CPU read_format ID|LOST disabled 1 inherit 1 mmap 1 comm 1 enable_on_exec 1 task 1 sample_id_all 1 mmap2 1 comm_exec 1 ksymbol 1 bpf_event 1 { wakeup_events, wakeup_watermark } 1 ------------------------------------------------------------ sys_perf_event_open: pid 1189569 cpu 0 group_fd -1 flags 0x8 sys_perf_event_open failed, error -13 perf_evlist__open: Permission denied ---- end(-2) ---- Leak of file descriptor 6 that opened: 'pipe:[14200347]' ---- unexpected signal (6) ---- iFailed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon Failed to read build ID for //anon #0 0x565358f6666e in child_test_sig_handler builtin-test.c:311 #1 0x7f29ce849df0 in __restore_rt libc_sigaction.c:0 #2 0x7f29ce89e95c in __pthread_kill_implementation pthread_kill.c:44 #3 0x7f29ce849cc2 in raise raise.c:27 #4 0x7f29ce8324ac in abort abort.c:81 #5 0x565358f662d4 in check_leaks builtin-test.c:226 #6 0x565358f6682e in run_test_child builtin-test.c:344 #7 0x565358ef7121 in start_command run-command.c:128 #8 0x565358f67273 in start_test builtin-test.c:545 #9 0x565358f6771d in __cmd_test builtin-test.c:647 #10 0x565358f682bd in cmd_test builtin-test.c:849 #11 0x565358ee5ded in run_builtin perf.c:349 #12 0x565358ee6085 in handle_internal_command perf.c:401 #13 0x565358ee61de in run_argv perf.c:448 #14 0x565358ee6527 in main perf.c:555 #15 0x7f29ce833ca8 in __libc_start_call_main libc_start_call_main.h:74 #16 0x7f29ce833d65 in __libc_start_main@@GLIBC_2.34 libc-start.c:128 #17 0x565358e391c1 in _start perf[851c1] 7: PERF_RECORD_* events & perf_sample fields : FAILED! ``` After: ``` $ perf test 7 7: PERF_RECORD_* events & perf_sample fields : Skip (permissions) ``` Fixes: 16d00fee703866c6 ("perf tests: Move test__PERF_RECORD into separate object") Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Chun-Tse Shao Cc: Howard Chu Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ed4e7d84edef07b3abb03017c6c2fd62336ec922 Author: Leo Yan Date: Fri Aug 8 14:24:40 2025 +0100 perf session: Fix handling when buffer exceeds 2 GiB [ Upstream commit c17dda8013495d8132c976cbf349be9949d0fbd1 ] If a user specifies an AUX buffer larger than 2 GiB, the returned size may exceed 0x80000000. Since the err variable is defined as a signed 32-bit integer, such a value overflows and becomes negative. As a result, the perf record command reports an error: 0x146e8 [0x30]: failed to process type: 71 [Unknown error 183711232] Change the type of the err variable to a signed 64-bit integer to accommodate large buffer sizes correctly. Fixes: d5652d865ea734a1 ("perf session: Add ability to skip 4GiB or more") Reported-by: Tamas Zsoldos Signed-off-by: Leo Yan Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Link: https://lore.kernel.org/r/20250808-perf_fix_big_buffer_size-v1-1-45f45444a9a4@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1459df54156543954c4906ef49d187647b2e7070 Author: Leo Yan Date: Fri Sep 12 16:42:09 2025 +0100 perf arm_spe: Correct memory level for remote access [ Upstream commit cb300e3515057fb555983ce47e8acc86a5c69c3c ] For remote accesses, the data source packet does not contain information about the memory level. To avoid misinformation, set the memory level to NA (Not Available). Fixes: 4e6430cbb1a9f1dc ("perf arm-spe: Use SPE data source for neoverse cores") Reviewed-by: James Clark Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ali Saidi Cc: German Gomez Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Will Deacon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b4d8cd590eaaa7b0c23b54172563cba97ecbacea Author: Leo Yan Date: Thu Oct 3 19:53:17 2024 +0100 perf arm-spe: Rename the common data source encoding [ Upstream commit 50b8f1d5bf4ad7f09ef8012ccf5f94f741df827b ] The Neoverse CPUs follow the common data source encoding, and other CPU variants can share the same format. Rename the CPU list and data source definitions as common data source names. This change prepares for appending more CPU variants. Signed-off-by: Leo Yan Reviewed-by: James Clark Link: https://lore.kernel.org/r/20241003185322.192357-3-leo.yan@arm.com Signed-off-by: Namhyung Kim Stable-dep-of: cb300e351505 ("perf arm_spe: Correct memory level for remote access") Signed-off-by: Sasha Levin commit d709eef7796f6ee50d87406842e3ff1c6d1f0402 Author: German Gomez Date: Mon Mar 20 15:15:06 2023 +0000 perf arm-spe: Refactor arm-spe to support operation packet type [ Upstream commit 0066015a3d8f9c01a17eb04579edba7dac9510af ] Extend the decoder of Arm SPE records to support more fields from the operation packet type. Not all fields are being decoded by this commit. Only those needed to support the use-case SVE load/store/other operations. Suggested-by: Leo Yan Signed-off-by: German Gomez Acked-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Anshuman.Khandual@arm.com Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Mark Rutland Cc: Mike Leach Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20230320151509.1137462-2-james.clark@arm.com Signed-off-by: James Clark Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: cb300e351505 ("perf arm_spe: Correct memory level for remote access") Signed-off-by: Sasha Levin commit 2c02259364949c91a7ddd5f6991497e6d2e6d6d7 Author: Leo Yan Date: Fri Sep 12 16:42:08 2025 +0100 perf arm_spe: Correct setting remote access [ Upstream commit 039fd0634a0629132432632d7ac9a14915406b5c ] Set the mem_remote field for a remote access to appropriately represent the event. Fixes: a89dbc9b988f3ba8 ("perf arm-spe: Set sample's data source field") Reviewed-by: James Clark Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ali Saidi Cc: German Gomez Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Will Deacon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 28dbbaf9ccfaf7bcbcbc43fe9609359bd883fb87 Author: Clément Le Goffic Date: Tue Jul 15 16:07:13 2025 +0200 rtc: optee: fix memory leak on driver removal [ Upstream commit a531350d2fe58f7fc4516e555f22391dee94efd9 ] Fix a memory leak in case of driver removal. Free the shared memory used for arguments exchanges between kernel and OP-TEE RTC PTA. Fixes: 81c2f059ab90 ("rtc: optee: add RTC driver for OP-TEE RTC PTA") Signed-off-by: Clément Le Goffic Link: https://lore.kernel.org/r/20250715-upstream-optee-rtc-v1-1-e0fdf8aae545@foss.st.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 03f967f944374376d4c836ff9eee6c32af8a509f Author: Rob Herring (Arm) Date: Thu Aug 21 16:57:02 2025 -0500 rtc: x1205: Fix Xicor X1205 vendor prefix [ Upstream commit 606d19ee37de3a72f1b6e95a4ea544f6f20dbb46 ] The vendor for the X1205 RTC is not Xircom, but Xicor which was acquired by Intersil. Since the I2C subsystem drops the vendor prefix for driver matching, the vendor prefix hasn't mattered. Fixes: 6875404fdb44 ("rtc: x1205: Add DT probing support") Signed-off-by: Rob Herring (Arm) Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250821215703.869628-2-robh@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit fadf0c073d97fa3c2dff7a5ccdfa82e05e6738e5 Author: Yunseong Kim Date: Fri Aug 22 16:25:08 2025 +0000 perf util: Fix compression checks returning -1 as bool [ Upstream commit 43fa1141e2c1af79c91aaa4df03e436c415a6fc3 ] The lzma_is_compressed and gzip_is_compressed functions are declared to return a "bool" type, but in case of an error (e.g., file open failure), they incorrectly returned -1. A bool type is a boolean value that is either true or false. Returning -1 for a bool return type can lead to unexpected behavior and may violate strict type-checking in some compilers. Fix the return value to be false in error cases, ensuring the function adheres to its declared return type improves for preventing potential bugs related to type mismatch. Fixes: 4b57fd44b61beb51 ("perf tools: Add lzma_is_compressed function") Reviewed-by: Ian Rogers Signed-off-by: Yunseong Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Stephen Brennan Link: https://lore.kernel.org/r/20250822162506.316844-3-ysk@kzalloc.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 69fd55ae1294e1476e7d89912fa0bbc7f81db20d Author: Brian Masney Date: Mon Aug 11 11:17:53 2025 -0400 clk: at91: peripheral: fix return value [ Upstream commit 47b13635dabc14f1c2fdcaa5468b47ddadbdd1b5 ] determine_rate() is expected to return an error code, or 0 on success. clk_sam9x5_peripheral_determine_rate() has a branch that returns the parent rate on a certain case. This is the behavior of round_rate(), so let's go ahead and fix this by setting req->rate. Fixes: b4c115c76184f ("clk: at91: clk-peripheral: add support for changeable parent rate") Reviewed-by: Alexander Sverdlin Acked-by: Nicolas Ferre Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 8926dae1ebce3ae0ef755d86f6b0e42ff96f8b66 Author: Ian Rogers Date: Thu Aug 21 09:38:19 2025 -0700 libperf event: Ensure tracing data is multiple of 8 sized [ Upstream commit b39c915a4f365cce6bdc0e538ed95d31823aea8f ] Perf's synthetic-events.c will ensure 8-byte alignment of tracing data, writing it after a perf_record_header_tracing_data event. Add padding to struct perf_record_header_tracing_data to make it 16-byte rather than 12-byte sized. Fixes: 055c67ed39887c55 ("perf tools: Move event synthesizing routines to separate .c file") Reviewed-by: James Clark Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Blake Jones Cc: Chun-Tse Shao Cc: Collin Funk Cc: Howard Chu Cc: Ingo Molnar Cc: Jan Polensky Cc: Jiri Olsa Cc: Kan Liang Cc: Li Huafei Cc: Mark Rutland Cc: Nam Cao Cc: Peter Zijlstra Cc: Steinar H. Gunderson Cc: Thomas Gleixner Link: https://lore.kernel.org/r/20250821163820.1132977-6-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7011bf1c967a7c1aba199568d526a395be242cba Author: Ian Rogers Date: Thu Aug 21 09:38:17 2025 -0700 perf evsel: Avoid container_of on a NULL leader [ Upstream commit 2354479026d726954ff86ce82f4b649637319661 ] An evsel should typically have a leader of itself, however, in tests like 'Sample parsing' a NULL leader may occur and the container_of will return a corrupt pointer. Avoid this with an explicit NULL test. Fixes: fba7c86601e2e42d ("libperf: Move 'leader' from tools/perf to perf_evsel::leader") Reviewed-by: James Clark Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Blake Jones Cc: Chun-Tse Shao Cc: Collin Funk Cc: Howard Chu Cc: Ingo Molnar Cc: Jan Polensky Cc: Jiri Olsa Cc: Kan Liang Cc: Li Huafei Cc: Mark Rutland Cc: Nam Cao Cc: Peter Zijlstra Cc: Steinar H. Gunderson Cc: Thomas Gleixner Link: https://lore.kernel.org/r/20250821163820.1132977-4-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5b0057459cdc243ffb35617603142dcace09c711 Author: Tomi Valkeinen Date: Fri Aug 8 11:59:15 2025 +0300 media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() commit f37df9a0eb5e43fcfe02cbaef076123dc0d79c7e upstream. v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try(). Signed-off-by: Tomi Valkeinen Fixes: 982c0487185b ("media: subdev: Add v4l2_subdev_call_state_try() macro") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/aJTNtpDUbTz7eyJc%40stanley.mountain/ Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2abfe0d32ba2e949ced933fede3667e94bbb0501 Author: Michael Hennerich Date: Fri Aug 29 12:25:43 2025 +0100 iio: frequency: adf4350: Fix ADF4350_REG3_12BIT_CLKDIV_MODE commit 1d8fdabe19267338f29b58f968499e5b55e6a3b6 upstream. The clk div bits (2 bits wide) do not start in bit 16 but in bit 15. Fix it accordingly. Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Link: https://patch.msgid.link/20250829-adf4350-fix-v2-2-0bf543ba797d@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d5a6942762e7d545ecf18951aa0ed378431f2d84 Author: Zhen Ni Date: Thu Aug 14 20:33:24 2025 +0800 clocksource/drivers/clps711x: Fix resource leaks in error paths commit cd32e596f02fc981674573402c1138f616df1728 upstream. The current implementation of clps711x_timer_init() has multiple error paths that directly return without releasing the base I/O memory mapped via of_iomap(). Fix of_iomap leaks in error paths. Fixes: 04410efbb6bc ("clocksource/drivers/clps711x: Convert init function to return error") Fixes: 2a6a8e2d9004 ("clocksource/drivers/clps711x: Remove board support") Signed-off-by: Zhen Ni Signed-off-by: Daniel Lezcano Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250814123324.1516495-1-zhen.ni@easystack.cn Signed-off-by: Greg Kroah-Hartman commit 7c1d0181211cf99f8561d140010b8c3b169b2c80 Author: Aleksa Sarai Date: Thu Aug 7 03:55:23 2025 +1000 fscontext: do not consume log entries when returning -EMSGSIZE commit 72d271a7baa7062cb27e774ac37c5459c6d20e22 upstream. Userspace generally expects APIs that return -EMSGSIZE to allow for them to adjust their buffer size and retry the operation. However, the fscontext log would previously clear the message even in the -EMSGSIZE case. Given that it is very cheap for us to check whether the buffer is too small before we remove the message from the ring buffer, let's just do that instead. While we're at it, refactor some fscontext_read() into a separate helper to make the ring buffer logic a bit easier to read. Fixes: 007ec26cdc9f ("vfs: Implement logging through fs_context") Cc: David Howells Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Aleksa Sarai Link: https://lore.kernel.org/20250807-fscontext-log-cleanups-v3-1-8d91d6242dc3@cyphar.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit fd85fc06325167e0b2a3ca3c685320384102dbd6 Author: Thomas Weißschuh Date: Tue Aug 5 14:38:08 2025 +0200 fs: always return zero on success from replace_fd() commit 708c04a5c2b78e22f56e2350de41feba74dfccd9 upstream. replace_fd() returns the number of the new file descriptor through the return value of do_dup2(). However its callers never care about the specific returned number. In fact the caller in receive_fd_replace() treats any non-zero return value as an error and therefore never calls __receive_sock() for most file descriptors, which is a bug. To fix the bug in receive_fd_replace() and to avoid the same issue happening in future callers, signal success through a plain zero. Suggested-by: Al Viro Link: https://lore.kernel.org/lkml/20250801220215.GS222315@ZenIV/ Fixes: 173817151b15 ("fs: Expand __receive_fd() to accept existing fd") Fixes: 42eb0d54c08a ("fs: split receive_fd_replace from __receive_fd") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/20250805-fix-receive_fd_replace-v3-1-b72ba8b34bac@linutronix.de Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman