commit 3dea0e7f549ee8ce3ce9d058d6d5c494d9ad02dc Author: Greg Kroah-Hartman Date: Fri Jun 27 11:05:38 2025 +0100 Linux 5.15.186 Link: https://lore.kernel.org/r/20250623130632.993849527@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Vijayendra Suman Signed-off-by: Greg Kroah-Hartman commit e3ff9f86cdb7b6b8d3bd7c73b7a413768dfc186c Author: Kees Cook Date: Fri May 2 15:41:57 2025 -0700 scsi: qedf: Use designated initializer for struct qed_fcoe_cb_ops commit d8720235d5b5cad86c1f07f65117ef2a96f8bec7 upstream. Recent fixes to the randstruct GCC plugin allowed it to notice that this structure is entirely function pointers and is therefore subject to randomization, but doing so requires that it always use designated initializers. Explicitly specify the "common" member as being initialized. Silences: drivers/scsi/qedf/qedf_main.c:702:9: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init] 702 | { | ^ Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Link: https://lore.kernel.org/r/20250502224156.work.617-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 8e31c6cc3cbac1d05cdca6e9c3c74653dd90a091 Author: Vitaliy Shevtsov Date: Thu Jun 12 21:35:18 2025 +0500 scsi: elx: efct: Fix memory leak in efct_hw_parse_filter() [ Upstream commit 2a8a5a5dd06eef580f9818567773fd75057cb875 ] strsep() modifies the address of the pointer passed to it so that it no longer points to the original address. This means kfree() gets the wrong pointer. Fix this by passing unmodified pointer returned from kstrdup() to kfree(). Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 4df84e846624 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Vitaliy Shevtsov Link: https://lore.kernel.org/r/20250612163616.24298-1-v.shevtsov@mt-integration.ru Reviewed-by: Daniel Wagner Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38 Author: Tengda Wu Date: Wed Jun 4 00:55:33 2025 +0000 arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() [ Upstream commit 39dfc971e42d886e7df01371cd1bef505076d84c ] KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()") As described in that commit, regs_get_kernel_stack_nth() has confirmed that `addr` is on the stack, so reading the value at `*addr` should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. Fixes: 0a8ea52c3eb1 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature") Signed-off-by: Tengda Wu Link: https://lore.kernel.org/r/20250604005533.1278992-1-wutengda@huaweicloud.com [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a9f6aab7910a0ef2895797f15c947f6d1053160f Author: Peter Zijlstra Date: Thu Jun 5 12:31:45 2025 +0200 perf: Fix sample vs do_exit() [ Upstream commit 4f6fc782128355931527cefe3eb45338abd8ab39 ] Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem. Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample") Reported-by: Baisheng Gao Suggested-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250605110815.GQ39944@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 4be8065eace76e33230e08875c10d56362ab00eb Author: Heiko Carstens Date: Mon May 19 18:07:11 2025 +0200 s390/pci: Fix __pcilg_mio_inuser() inline assembly commit c4abe6234246c75cdc43326415d9cff88b7cf06c upstream. Use "a" constraint for the shift operand of the __pcilg_mio_inuser() inline assembly. The used "d" constraint allows the compiler to use any general purpose register for the shift operand, including register zero. If register zero is used this my result in incorrect code generation: 8f6: a7 0a ff f8 ahi %r0,-8 8fa: eb 32 00 00 00 0c srlg %r3,%r2,0 <---- If register zero is selected to contain the shift value, the srlg instruction ignores the contents of the register and always shifts zero bits. Therefore use the "a" constraint which does not permit to select register zero. Fixes: f058599e22d5 ("s390/pci: Fix s390_mmio_read/write with MIO") Cc: stable@vger.kernel.org Reported-by: Niklas Schnelle Reviewed-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Niklas Schnelle Signed-off-by: Greg Kroah-Hartman commit 6d7fcd8a7a42775aca8fff702acfb83e4dcd5f0f Author: Paul Chaignon Date: Thu May 29 12:28:35 2025 +0200 bpf: Fix L4 csum update on IPv6 in CHECKSUM_COMPLETE commit ead7f9b8de65632ef8060b84b0c55049a33cfea1 upstream. In Cilium, we use bpf_csum_diff + bpf_l4_csum_replace to, among other things, update the L4 checksum after reverse SNATing IPv6 packets. That use case is however not currently supported and leads to invalid skb->csum values in some cases. This patch adds support for IPv6 address changes in bpf_l4_csum_update via a new flag. When calling bpf_l4_csum_replace in Cilium, it ends up calling inet_proto_csum_replace_by_diff: 1: void inet_proto_csum_replace_by_diff(__sum16 *sum, struct sk_buff *skb, 2: __wsum diff, bool pseudohdr) 3: { 4: if (skb->ip_summed != CHECKSUM_PARTIAL) { 5: csum_replace_by_diff(sum, diff); 6: if (skb->ip_summed == CHECKSUM_COMPLETE && pseudohdr) 7: skb->csum = ~csum_sub(diff, skb->csum); 8: } else if (pseudohdr) { 9: *sum = ~csum_fold(csum_add(diff, csum_unfold(*sum))); 10: } 11: } The bug happens when we're in the CHECKSUM_COMPLETE state. We've just updated one of the IPv6 addresses. The helper now updates the L4 header checksum on line 5. Next, it updates skb->csum on line 7. It shouldn't. For an IPv6 packet, the updates of the IPv6 address and of the L4 checksum will cancel each other. The checksums are set such that computing a checksum over the packet including its checksum will result in a sum of 0. So the same is true here when we update the L4 checksum on line 5. We'll update it as to cancel the previous IPv6 address update. Hence skb->csum should remain untouched in this case. The same bug doesn't affect IPv4 packets because, in that case, three fields are updated: the IPv4 address, the IP checksum, and the L4 checksum. The change to the IPv4 address and one of the checksums still cancel each other in skb->csum, but we're left with one checksum update and should therefore update skb->csum accordingly. That's exactly what inet_proto_csum_replace_by_diff does. This special case for IPv6 L4 checksums is also described atop inet_proto_csum_replace16, the function we should be using in this case. This patch introduces a new bpf_l4_csum_replace flag, BPF_F_IPV6, to indicate that we're updating the L4 checksum of an IPv6 packet. When the flag is set, inet_proto_csum_replace_by_diff will skip the skb->csum update. Fixes: 7d672345ed295 ("bpf: add generic bpf_csum_diff helper") Signed-off-by: Paul Chaignon Acked-by: Daniel Borkmann Link: https://patch.msgid.link/96a6bc3a443e6f0b21ff7b7834000e17fb549e05.1748509484.git.paul.chaignon@gmail.com Signed-off-by: Jakub Kicinski [ Note: Fixed conflict due to unrelated comment change. ] Signed-off-by: Paul Chaignon Signed-off-by: Greg Kroah-Hartman commit f02c9c448e50e76ba73c6c94a0029043e53dd6a5 Author: Paul Chaignon Date: Thu May 29 12:28:05 2025 +0200 net: Fix checksum update for ILA adj-transport commit 6043b794c7668c19dabc4a93c75b924a19474d59 upstream. During ILA address translations, the L4 checksums can be handled in different ways. One of them, adj-transport, consist in parsing the transport layer and updating any found checksum. This logic relies on inet_proto_csum_replace_by_diff and produces an incorrect skb->csum when in state CHECKSUM_COMPLETE. This bug can be reproduced with a simple ILA to SIR mapping, assuming packets are received with CHECKSUM_COMPLETE: $ ip a show dev eth0 14: eth0@if15: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 62:ae:35:9e:0f:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 3333:0:0:1::c078/64 scope global valid_lft forever preferred_lft forever inet6 fd00:10:244:1::c078/128 scope global nodad valid_lft forever preferred_lft forever inet6 fe80::60ae:35ff:fe9e:f8d/64 scope link proto kernel_ll valid_lft forever preferred_lft forever $ ip ila add loc_match fd00:10:244:1 loc 3333:0:0:1 \ csum-mode adj-transport ident-type luid dev eth0 Then I hit [fd00:10:244:1::c078]:8000 with a server listening only on [3333:0:0:1::c078]:8000. With the bug, the SYN packet is dropped with SKB_DROP_REASON_TCP_CSUM after inet_proto_csum_replace_by_diff changed skb->csum. The translation and drop are visible on pwru [1] traces: IFACE TUPLE FUNC eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) ipv6_rcv eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) ip6_rcv_core eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) nf_hook_slow eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) inet_proto_csum_replace_by_diff eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) tcp_v6_early_demux eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_route_input eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_input eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_input_finish eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_protocol_deliver_rcu eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) raw6_local_deliver eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ipv6_raw_deliver eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) tcp_v6_rcv eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) __skb_checksum_complete eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) kfree_skb_reason(SKB_DROP_REASON_TCP_CSUM) eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_release_head_state eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_release_data eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_free_head eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) kfree_skbmem This is happening because inet_proto_csum_replace_by_diff is updating skb->csum when it shouldn't. The L4 checksum is updated such that it "cancels" the IPv6 address change in terms of checksum computation, so the impact on skb->csum is null. Note this would be different for an IPv4 packet since three fields would be updated: the IPv4 address, the IP checksum, and the L4 checksum. Two would cancel each other and skb->csum would still need to be updated to take the L4 checksum change into account. This patch fixes it by passing an ipv6 flag to inet_proto_csum_replace_by_diff, to skip the skb->csum update if we're in the IPv6 case. Note the behavior of the only other user of inet_proto_csum_replace_by_diff, the BPF subsystem, is left as is in this patch and fixed in the subsequent patch. With the fix, using the reproduction from above, I can confirm skb->csum is not touched by inet_proto_csum_replace_by_diff and the TCP SYN proceeds to the application after the ILA translation. Link: https://github.com/cilium/pwru [1] Fixes: 65d7ab8de582 ("net: Identifier Locator Addressing module") Signed-off-by: Paul Chaignon Acked-by: Daniel Borkmann Link: https://patch.msgid.link/b5539869e3550d46068504feb02d37653d939c0b.1748509484.git.paul.chaignon@gmail.com Signed-off-by: Jakub Kicinski [ Fixed conflict due to unrelated change in inet_proto_csum_replace_by_diff. ] Signed-off-by: Paul Chaignon Signed-off-by: Greg Kroah-Hartman commit ecbea1a5fec52096db7d8f0da5ab7b67c1783df2 Author: Jan Kara Date: Sat Oct 5 00:15:56 2024 +0200 ext4: avoid remount errors with 'abort' mount option commit 76486b104168ae59703190566e372badf433314b upstream. When we remount filesystem with 'abort' mount option while changing other mount options as well (as is LTP test doing), we can return error from the system call after commit d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors") because the application of mount option changes detects shutdown filesystem and refuses to do anything. The behavior of application of other mount options in presence of 'abort' mount option is currently rather arbitary as some mount option changes are handled before 'abort' and some after it. Move aborting of the filesystem to the end of remount handling so all requested changes are properly applied before the filesystem is shutdown to have a reasonably consistent behavior. Fixes: d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors") Reported-by: Jan Stancek Link: https://lore.kernel.org/all/Zvp6L+oFnfASaoHl@t14s Signed-off-by: Jan Kara Tested-by: Jan Stancek Link: https://patch.msgid.link/20241004221556.19222-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 1578f57a3fc338f0607c32002c40e82347b8b443 Author: Jan Kara Date: Fri Jun 16 18:50:50 2023 +0200 ext4: make 'abort' mount option handling standard commit 22b8d707b07e6e06f50fe1d9ca8756e1f894eb0d upstream. 'abort' mount option is the only mount option that has special handling and sets a bit in sbi->s_mount_flags. There is not strong reason for that so just simplify the code and make 'abort' set a bit in sbi->s_mount_opt2 as any other mount option. This simplifies the code and will allow us to drop EXT4_MF_FS_ABORTED completely in the following patch. Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20230616165109.21695-4-jack@suse.cz Signed-off-by: Theodore Ts'o Stable-dep-of: 76486b104168 ("ext4: avoid remount errors with 'abort' mount option") Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit ef5706bed97e240b4abf4233ceb03da7336bc775 Author: Gavin Guo Date: Mon Apr 21 19:35:36 2025 +0800 mm/huge_memory: fix dereferencing invalid pmd migration entry commit be6e843fc51a584672dfd9c4a6a24c8cb81d5fb7 upstream. When migrating a THP, concurrent access to the PMD migration entry during a deferred split scan can lead to an invalid address access, as illustrated below. To prevent this invalid access, it is necessary to check the PMD migration entry and return early. In this context, there is no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the equality of the target folio. Since the PMD migration entry is locked, it cannot be served as the target. Mailing list discussion and explanation from Hugh Dickins: "An anon_vma lookup points to a location which may contain the folio of interest, but might instead contain another folio: and weeding out those other folios is precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of replacing the wrong folio" comment a few lines above it) is for." BUG: unable to handle page fault for address: ffffea60001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60 Call Trace: try_to_migrate_one+0x28c/0x3730 rmap_walk_anon+0x4f6/0x770 unmap_folio+0x196/0x1f0 split_huge_page_to_list_to_order+0x9f6/0x1560 deferred_split_scan+0xac5/0x12a0 shrinker_debugfs_scan_write+0x376/0x470 full_proxy_write+0x15c/0x220 vfs_write+0x2fc/0xcb0 ksys_write+0x146/0x250 do_syscall_64+0x6a/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e The bug is found by syzkaller on an internal kernel, then confirmed on upstream. Link: https://lkml.kernel.org/r/20250421113536.3682201-1-gavinguo@igalia.com Link: https://lore.kernel.org/all/20250414072737.1698513-1-gavinguo@igalia.com/ Link: https://lore.kernel.org/all/20250418085802.2973519-1-gavinguo@igalia.com/ Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path") Signed-off-by: Gavin Guo Acked-by: David Hildenbrand Acked-by: Hugh Dickins Acked-by: Zi Yan Reviewed-by: Gavin Shan Cc: Florent Revest Cc: Matthew Wilcox (Oracle) Cc: Miaohe Lin Cc: Signed-off-by: Andrew Morton [gavin: backport the migration checking logic to __split_huge_pmd] Signed-off-by: Gavin Guo Signed-off-by: Greg Kroah-Hartman commit 956b5aebb349449b38d920d444ca1392d43719d1 Author: Eric Dumazet Date: Fri Jun 20 15:46:23 2025 +0000 net_sched: sch_sfq: reject invalid perturb period commit 7ca52541c05c832d32b112274f81a985101f9ba8 upstream. Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. Tested: tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Gerrard Tai Signed-off-by: Eric Dumazet Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250611083501.1810459-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6c589aa318023690f1606c666a7fb5f4c1c9c219 Author: Octavian Purdila Date: Fri Jun 20 15:46:21 2025 +0000 net_sched: sch_sfq: move the limit validation commit b3bf8f63e6179076b57c9de660c9f80b5abefe70 upstream. It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed. Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations: tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1 This fixes the following syzkaller reported crash: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375 Reported-by: syzbot Fixes: 10685681bafc ("net_sched: sch_sfq: don't allow 1 packet limit") Signed-off-by: Octavian Purdila Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6b96d7a9e8e79b05c349db5472118c8574327901 Author: Octavian Purdila Date: Fri Jun 20 15:46:20 2025 +0000 net_sched: sch_sfq: use a temporary work area for validating configuration commit 8c0cea59d40cf6dd13c2950437631dd614fbade6 upstream. Many configuration parameters have influence on others (e.g. divisor -> flows -> limit, depth -> limit) and so it is difficult to correctly do all of the validation before applying the configuration. And if a validation error is detected late it is difficult to roll back a partially applied configuration. To avoid these issues use a temporary work area to update and validate the configuration and only then apply the configuration to the internal state. Signed-off-by: Octavian Purdila Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1b562b7f9231432da40d12e19786c1bd7df653a7 Author: Octavian Purdila Date: Fri Jun 20 15:46:19 2025 +0000 net_sched: sch_sfq: don't allow 1 packet limit commit 10685681bafce6febb39770f3387621bf5d67d0b upstream. The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. Reported-by: syzbot Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Octavian Purdila Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20241204030520.2084663-2-tavip@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 548cf048b426729a7a1fa6acd1271c010c9a7380 Author: Eric Dumazet Date: Fri Jun 20 15:46:18 2025 +0000 net_sched: sch_sfq: handle bigger packets commit e4650d7ae4252f67e997a632adfae0dd74d3a99a upstream. SFQ has an assumption on dealing with packets smaller than 64KB. Even before BIG TCP, TCA_STAB can provide arbitrary big values in qdisc_pkt_len(skb) It is time to switch (struct sfq_slot)->allot to a 32bit field. sizeof(struct sfq_slot) is now 64 bytes, giving better cache locality. Signed-off-by: Eric Dumazet Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20241008111603.653140-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8a1eca8985804db008af0708183b8e7381e441c3 Author: Eric Dumazet Date: Fri Jun 20 15:46:17 2025 +0000 net_sched: sch_sfq: annotate data-races around q->perturb_period commit a17ef9e6c2c1cf0fc6cd6ca6a9ce525c67d1da7f upstream. sfq_perturbation() reads q->perturb_period locklessly. Add annotations to fix potential issues. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240430180015.3111398-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 98236b25d03f3f83f268236cb9b83c4cabd60ab9 Author: James Morse Date: Sat Jun 7 15:35:35 2025 +0000 arm64: proton-pack: Add new CPUs 'k' values for branch mitigation [ Upstream commit efe676a1a7554219eae0b0dcfe1e0cdcc9ef9aef ] Update the list of 'k' values for the branch mitigation from arm's website. Add the values for Cortex-X1C. The MIDR_EL1 value can be found here: https://developer.arm.com/documentation/101968/0002/Register-descriptions/AArch> Link: https://developer.arm.com/documentation/110280/2-0/?lang=en Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit df53d418709205450a02bb4d71cbfb4ff86f2c1e Author: James Morse Date: Sat Jun 7 15:35:34 2025 +0000 arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users [ Upstream commit f300769ead032513a68e4a02e806393402e626f8 ] Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Acked-by: Daniel Borkmann Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit 993f63239c219696aef8887a4e7d3a16bf5a8ece Author: James Morse Date: Sat Jun 7 15:35:33 2025 +0000 arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs [ Upstream commit 0dfefc2ea2f29ced2416017d7e5b1253a54c2735 ] A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Acked-by: Daniel Borkmann Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit d759395f25cac353c946d32919c2970d55a5d452 Author: Liu Song Date: Sat Jun 7 15:35:32 2025 +0000 arm64: spectre: increase parameters that can be used to turn off bhb mitigation individually [ Upstream commit 877ace9eab7de032f954533afd5d1ecd0cf62eaf ] In our environment, it was found that the mitigation BHB has a great impact on the benchmark performance. For example, in the lmbench test, the "process fork && exit" test performance drops by 20%. So it is necessary to have the ability to turn off the mitigation individually through cmdline, thus avoiding having to compile the kernel by adjusting the config. Signed-off-by: Liu Song Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/1661514050-22263-1-git-send-email-liusong@linux.alibaba.com Signed-off-by: Catalin Marinas Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit fc061c32e32709e139e7af963e2fbe88683154e1 Author: James Morse Date: Sat Jun 7 15:35:31 2025 +0000 arm64: proton-pack: Expose whether the branchy loop k value [ Upstream commit a1152be30a043d2d4dcb1683415f328bf3c51978 ] Add a helper to expose the k value of the branchy loop. This is needed by the BPF JIT to generate the mitigation sequence in BPF programs. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit 005f3b7bd3787a2c246f08b7190aa3289378e1dd Author: James Morse Date: Sat Jun 7 15:35:30 2025 +0000 arm64: proton-pack: Expose whether the platform is mitigated by firmware [ Upstream commit e7956c92f396a44eeeb6eaf7a5b5e1ad24db6748 ] is_spectre_bhb_fw_affected() allows the caller to determine if the CPU is known to need a firmware mitigation. CPUs are either on the list of CPUs we know about, or firmware has been queried and reported that the platform is affected - and mitigated by firmware. This helper is not useful to determine if the platform is mitigated by firmware. A CPU could be on the know list, but the firmware may not be implemented. Its affected but not mitigated. spectre_bhb_enable_mitigation() handles this distinction by checking the firmware state before enabling the mitigation. Add a helper to expose this state. This will be used by the BPF JIT to determine if calling firmware for a mitigation is necessary and supported. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit 3af65d4123fe8353c30ba64507e37bfae56a7650 Author: James Morse Date: Sat Jun 7 15:35:29 2025 +0000 arm64: insn: Add support for encoding DSB [ Upstream commit 63de8abd97ddb9b758bd8f915ecbd18e1f1a87a0 ] To generate code in the eBPF epilogue that uses the DSB instruction, insn.c needs a heler to encode the type and domain. Re-use the crm encoding logic from the DMB instruction. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit 803228bb5ad9b9e6b6355c3a0d2b637e4b122c72 Author: Hou Tao Date: Sat Jun 7 15:35:28 2025 +0000 arm64: insn: add encoders for atomic operations [ Upstream commit fa1114d9eba5087ba5e81aab4c56f546995e6cd3 ] It is a preparation patch for eBPF atomic supports under arm64. eBPF needs support atomic[64]_fetch_add, atomic[64]_[fetch_]{and,or,xor} and atomic[64]_{xchg|cmpxchg}. The ordering semantics of eBPF atomics are the same with the implementations in linux kernel. Add three helpers to support LDCLR/LDEOR/LDSET/SWP, CAS and DMB instructions. STADD/STCLR/STEOR/STSET are simply encoded as aliases for LDADD/LDCLR/LDEOR/LDSET with XZR as the destination register, so no extra helper is added. atomic_fetch_add() and other atomic ops needs support for STLXR instruction, so extend enum aarch64_insn_ldst_type to do that. LDADD/LDEOR/LDSET/SWP and CAS instructions are only available when LSE atomics is enabled, so just return AARCH64_BREAK_FAULT directly in these newly-added helpers if CONFIG_ARM64_LSE_ATOMICS is disabled. Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20220217072232.1186625-3-houtao1@huawei.com Signed-off-by: Will Deacon Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit 0fc6db6d17bbc85e527ed5012e57522229e89d19 Author: Hou Tao Date: Sat Jun 7 15:35:27 2025 +0000 arm64: move AARCH64_BREAK_FAULT into insn-def.h [ Upstream commit 97e58e395e9c074fd096dad13c54e9f4112cf71d ] If CONFIG_ARM64_LSE_ATOMICS is off, encoders for LSE-related instructions can return AARCH64_BREAK_FAULT directly in insn.h. In order to access AARCH64_BREAK_FAULT in insn.h, we can not include debug-monitors.h in insn.h, because debug-monitors.h has already depends on insn.h, so just move AARCH64_BREAK_FAULT into insn-def.h. It will be used by the following patch to eliminate unnecessary LSE-related encoders when CONFIG_ARM64_LSE_ATOMICS is off. Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20220217072232.1186625-2-houtao1@huawei.com Signed-off-by: Will Deacon Signed-off-by: Pu Lehui Signed-off-by: Greg Kroah-Hartman commit cebd765ba328092f250210f258ead58e52106225 Author: Jon Hunter Date: Thu Jun 5 13:52:59 2025 +0100 Revert "cpufreq: tegra186: Share policy per cluster" This reverts commit 89172666228de1cefcacf5bc6f61c6281751d2ed which is upstream commit be4ae8c19492cd6d5de61ccb34ffb3f5ede5eec8. This commit is causing a suspend regression on Tegra186 Jetson TX2 with Linux v6.12.y kernels. This is not seen with Linux v6.15 that includes this change but indicates that there are there changes missing. Therefore, revert this change. Link: https://lore.kernel.org/linux-tegra/bf1dabf7-0337-40e9-8b8e-4e93a0ffd4cc@nvidia.com/ Fixes: 89172666228d ("cpufreq: tegra186: Share policy per cluster") Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 9051e4373dd1e7b94e114a91f1ff8b718e0a1758 Author: Claudiu Beznea Date: Thu Jan 16 20:22:49 2025 +0200 serial: sh-sci: Increment the runtime usage counter for the earlycon device commit 651dee03696e1dfde6d9a7e8664bbdcd9a10ea7f upstream. In the sh-sci driver, serial ports are mapped to the sci_ports[] array, with earlycon mapped at index zero. The uart_add_one_port() function eventually calls __device_attach(), which, in turn, calls pm_request_idle(). The identified code path is as follows: uart_add_one_port() -> serial_ctrl_register_port() -> serial_core_register_port() -> serial_core_port_device_add() -> serial_base_port_add() -> device_add() -> bus_probe_device() -> device_initial_probe() -> __device_attach() -> // ... if (dev->p->dead) { // ... } else if (dev->driver) { // ... } else { // ... pm_request_idle(dev); // ... } The earlycon device clocks are enabled by the bootloader. However, the pm_request_idle() call in __device_attach() disables the SCI port clocks while earlycon is still active. The earlycon write function, serial_console_write(), calls sci_poll_put_char() via serial_console_putchar(). If the SCI port clocks are disabled, writing to earlycon may sometimes cause the SR.TDFE bit to remain unset indefinitely, causing the while loop in sci_poll_put_char() to never exit. On single-core SoCs, this can result in the system being blocked during boot when this issue occurs. To resolve this, increment the runtime PM usage counter for the earlycon SCI device before registering the UART port. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250116182249.3828577-6-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit ee195051be2db6b82980053e45c7e892019c22ab Author: Geert Uytterhoeven Date: Thu Oct 31 10:29:51 2024 +0100 ARM: dts: am335x-bone-common: Increase MDIO reset deassert delay to 50ms commit 929d8490f8790164f5f63671c1c58d6c50411cb2 upstream. Commit b9bf5612610aa7e3 ("ARM: dts: am335x-bone-common: Increase MDIO reset deassert time") already increased the MDIO reset deassert delay from 6.5 to 13 ms, but this may still cause Ethernet PHY probe failures: SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC LAN8710/LAN8720 failed with error -5 On BeagleBone Black Rev. C3, ETH_RESETn is controlled by an open-drain AND gate. It is pulled high by a 10K resistor, and has a 4.7µF capacitor to ground, giving an RC time constant of 47ms. As it takes 0.7RC to charge the capacitor above the threshold voltage of a CMOS input (VDD/2), the delay should be at least 33ms. Considering the typical tolerance of 20% on capacitors, 40ms would be safer. Add an additional safety margin and settle for 50ms. Signed-off-by: Geert Uytterhoeven Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/9002a58daa1b2983f39815b748ee9d2f8dcc4829.1730366936.git.geert+renesas@glider.be Signed-off-by: Kevin Hilman Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman commit 1a233520de8cb614cdd087c1c0475aba3476c0b4 Author: Colin Foster Date: Fri May 31 13:38:17 2024 -0500 ARM: dts: am335x-bone-common: Increase MDIO reset deassert time commit b9bf5612610aa7e38d58fee16f489814db251c01 upstream. Prior to commit df16c1c51d81 ("net: phy: mdio_device: Reset device only when necessary") MDIO reset deasserts were performed twice during boot. Now that the second deassert is no longer performed, device probe failures happen due to the change in timing with the following error message: SMSC LAN8710/LAN8720: probe of 4a101000.mdio:00 failed with error -5 Restore the original effective timing, which resolves the probe failures. Signed-off-by: Colin Foster Link: https://lore.kernel.org/r/20240531183817.2698445-1-colin.foster@in-advantage.com Signed-off-by: Kevin Hilman Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman commit 57a00096a11bdc74103d16c8e1afd65be9304b03 Author: Shengyu Qu Date: Sun Aug 6 16:50:44 2023 +0800 ARM: dts: am335x-bone-common: Add GPIO PHY reset on revision C3 board commit 623cef652768860bd5f205fb7b741be278585fba upstream. This patch adds ethernet PHY reset GPIO config for Beaglebone Black series boards with revision C3. This fixes a random phy startup failure bug discussed at [1]. The GPIO pin used for reset is not used on older revisions, so it is ok to apply to all board revisions. The reset timing was discussed and tested at [2]. [1] https://forum.digikey.com/t/ethernet-device-is-not-detecting-on-ubuntu-20-04-lts-on-bbg/19948 [2] https://forum.beagleboard.org/t/recognizing-a-beaglebone-black-rev-c3-board/31249/ Signed-off-by: Robert Nelson Signed-off-by: Shengyu Qu Message-ID: Signed-off-by: Tony Lindgren Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman commit ca3829c18c8d0ceb656605d3bff6bb3dfb078589 Author: Eric Dumazet Date: Wed Jun 18 14:08:44 2025 +0000 net: atm: fix /proc/net/atm/lec handling [ Upstream commit d03b79f459c7935cff830d98373474f440bd03ae ] /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Acked-by: Francois Romieu # Minor atm contributor Link: https://patch.msgid.link/20250618140844.1686882-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17e156a94e94a906a570dbf9b48877956c60bef8 Author: Eric Dumazet Date: Wed Jun 18 14:08:43 2025 +0000 net: atm: add lec_mutex [ Upstream commit d13a3824bfd2b4774b671a75cf766a16637a0e67 ] syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142 CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+8b64dec3affaed7b3af5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6852c6f6.050a0220.216029.0018.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250618140844.1686882-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc724bd34d56f5589f7587a091a8cda2386826c4 Author: Kuniyuki Iwashima Date: Tue Jun 17 15:40:42 2025 -0700 calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). [ Upstream commit 10876da918fa1aec0227fb4c67647513447f53a9 ] syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0] The NULL is of struct sock, which was fetched by sk_to_full_sk() in calipso_req_setattr(). Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log. Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener 1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood"). As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie. Let's return an error in calipso_req_setattr() and calipso_req_delattr() in the SYN Cookie case. This can be reproduced by [1] on Fedora and now connect() of nc times out. [0]: TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ipv6_rcv+0xf9/0x490 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1f0 net/core/dev.c:5896 __netif_receive_skb+0x1d/0x170 net/core/dev.c:6009 process_backlog+0x41e/0x13b0 net/core/dev.c:6357 __napi_poll+0xbd/0x710 net/core/dev.c:7191 napi_poll net/core/dev.c:7260 [inline] net_rx_action+0x9de/0xde0 net/core/dev.c:7382 handle_softirqs+0x19a/0x770 kernel/softirq.c:561 do_softirq.part.0+0x36/0x70 kernel/softirq.c:462 do_softirq arch/x86/include/asm/preempt.h:26 [inline] __local_bh_enable_ip+0xf1/0x110 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0xc2a/0x3c40 net/core/dev.c:4679 dev_queue_xmit include/linux/netdevice.h:3313 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip6_finish_output2+0xd69/0x1f80 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x5dc/0xd60 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x24b/0x8d0 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:459 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_xmit+0xbbc/0x20d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x39a/0x720 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x1a7b/0x3b40 net/ipv4/tcp_output.c:1471 tcp_transmit_skb net/ipv4/tcp_output.c:1489 [inline] tcp_send_syn_data net/ipv4/tcp_output.c:4059 [inline] tcp_connect+0x1c0c/0x4510 net/ipv4/tcp_output.c:4148 tcp_v6_connect+0x156c/0x2080 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x3a7/0xed0 net/ipv4/af_inet.c:677 tcp_sendmsg_fastopen+0x3e2/0x710 net/ipv4/tcp.c:1039 tcp_sendmsg_locked+0x1e82/0x3570 net/ipv4/tcp.c:1091 tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1358 inet6_sendmsg+0xb9/0x150 net/ipv6/af_inet6.c:659 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xf4/0x2a0 net/socket.c:733 __sys_sendto+0x29a/0x390 net/socket.c:2187 __do_sys_sendto net/socket.c:2194 [inline] __se_sys_sendto net/socket.c:2190 [inline] __x64_sys_sendto+0xe1/0x1c0 net/socket.c:2190 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f06553c47ed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0653a06fc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f0655605fa0 RCX: 00007f06553c47ed RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000b RBP: 00007f065545db38 R08: 0000200000000140 R09: 000000000000001c R10: f7384d4ea84b01bd R11: 0000000000000246 R12: 0000000000000000 R13: 00007f0655605fac R14: 00007f0655606038 R15: 00007f06539e7000 Modules linked in: [1]: dnf install -y selinux-policy-targeted policycoreutils netlabel_tools procps-ng nmap-ncat mount -t selinuxfs none /sys/fs/selinux load_policy netlabelctl calipso add pass doi:1 netlabelctl map del default netlabelctl map add default address:::1 protocol:calipso,1 sysctl net.ipv4.tcp_syncookies=2 nc -l ::1 80 & nc ::1 80 Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.") Reported-by: syzkaller Reported-by: John Cheung Closes: https://lore.kernel.org/netdev/CAP=Rh=MvfhrGADy+-WJiftV2_WzMH4VEhEFmeT28qY+4yxNu4w@mail.gmail.com/ Signed-off-by: Kuniyuki Iwashima Acked-by: Paul Moore Link: https://patch.msgid.link/20250617224125.17299-1-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8595350615f952fcf8bc861464a6bf6b1129af50 Author: Haixia Qu Date: Tue Jun 17 05:56:24 2025 +0000 tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer [ Upstream commit f82727adcf2992822e12198792af450a76ebd5ef ] The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer , priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0 the ub was in fact a struct dev. when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it. fix this by checking media_id. Fixes: 832629ca5c313 ("tipc: add UDP remoteip dump to netlink API") Signed-off-by: Haixia Qu Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20250617055624.2680-1-hxqu@hillstonenet.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d54e0c077b7c30af2890a0b662d32e5a87a4d5d9 Author: Neal Cardwell Date: Fri Jun 13 15:30:56 2025 -0400 tcp: fix tcp_packet_delayed() for tcp_is_non_sack_preventing_reopen() behavior [ Upstream commit d0fa59897e049e84432600e86df82aab3dce7aa5 ] After the following commit from 2024: commit e37ab7373696 ("tcp: fix to allow timestamp undo if no retransmits were sent") ...there was buggy behavior where TCP connections without SACK support could easily see erroneous undo events at the end of fast recovery or RTO recovery episodes. The erroneous undo events could cause those connections to suffer repeated loss recovery episodes and high retransmit rates. The problem was an interaction between the non-SACK behavior on these connections and the undo logic. The problem is that, for non-SACK connections at the end of a loss recovery episode, if snd_una == high_seq, then tcp_is_non_sack_preventing_reopen() holds steady in CA_Recovery or CA_Loss, but clears tp->retrans_stamp to 0. Then upon the next ACK the "tcp: fix to allow timestamp undo if no retransmits were sent" logic saw the tp->retrans_stamp at 0 and erroneously concluded that no data was retransmitted, and erroneously performed an undo of the cwnd reduction, restoring cwnd immediately to the value it had before loss recovery. This caused an immediate burst of traffic and build-up of queues and likely another immediate loss recovery episode. This commit fixes tcp_packet_delayed() to ignore zero retrans_stamp values for non-SACK connections when snd_una is at or above high_seq, because tcp_is_non_sack_preventing_reopen() clears retrans_stamp in this case, so it's not a valid signal that we can undo. Note that the commit named in the Fixes footer restored long-present behavior from roughly 2005-2019, so apparently this bug was present for a while during that era, and this was simply not caught. Fixes: e37ab7373696 ("tcp: fix to allow timestamp undo if no retransmits were sent") Reported-by: Eric Wheeler Closes: https://lore.kernel.org/netdev/64ea9333-e7f9-0df-b0f2-8d566143acab@ewheeler.net/ Signed-off-by: Neal Cardwell Co-developed-by: Yuchung Cheng Signed-off-by: Yuchung Cheng Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1b0ad18704913c92a3ad53748fbc0f219a75b876 Author: Kuniyuki Iwashima Date: Mon Jun 16 11:21:14 2025 -0700 atm: atmtcp: Free invalid length skb in atmtcp_c_send(). [ Upstream commit 2f370ae1fb6317985f3497b1bb80d457508ca2f7 ] syzbot reported the splat below. [0] vcc_sendmsg() copies data passed from userspace to skb and passes it to vcc->dev->ops->send(). atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after checking if skb->len is 0, but it's not enough. Also, when skb->len == 0, skb and sk (vcc) were leaked because dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing to revert atm_account_tx() in vcc_sendmsg(), which is expected to be done in atm_pop_raw(). Let's properly free skb with an invalid length in atmtcp_c_send(). [0]: BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+1d3c235276f62963e93a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1d3c235276f62963e93a Tested-by: syzbot+1d3c235276f62963e93a@syzkaller.appspotmail.com Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250616182147.963333-2-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8cd847fb8626872631cc22d44be5127b4ebfb74 Author: Kuniyuki Iwashima Date: Mon Jun 16 13:15:12 2025 -0700 mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). [ Upstream commit 6dbb0d97c5096072c78a6abffe393584e57ae945 ] As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL. net->mpls.platform_label is only updated under RTNL. Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat. [0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ---------------------------- net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961 stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 Fixes: 0189197f4416 ("mpls: Basic routing support") Reported-by: syzbot+8a583bdd1a5cc0b0e068@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68507981.a70a0220.395abc.01ef.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250616201532.1036568-1-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 527fad1ae32ffa2d4853a1425fe1c8dbb8c9744c Author: Dmitry Antipov Date: Mon Jun 16 21:12:05 2025 +0300 wifi: carl9170: do not ping device which has failed to load firmware [ Upstream commit 15d25307692312cec4b57052da73387f91a2e870 ] Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 Fixes: e4a668c59080 ("carl9170: fix spurious restart due to high latency") Signed-off-by: Dmitry Antipov Acked-by: Christian Lamparter Link: https://patch.msgid.link/20250616181205.38883-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5adc79cfdd211cd939b29cdf82d45121220674b3 Author: Vladimir Oltean Date: Fri Jun 13 20:47:48 2025 +0300 ptp: fix breakage after ptp_vclock_in_use() rework [ Upstream commit 5ab73b010cad294851e558f1d4714a85c6f206c7 ] What is broken -------------- ptp4l, and any other application which calls clock_adjtime() on a physical clock, is greeted with error -EBUSY after commit 87f7ce260a3c ("ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()"). Explanation for the breakage ---------------------------- The blamed commit was based on the false assumption that ptp_vclock_in_use() callers already test for n_vclocks prior to calling this function. This is notably incorrect for the code path below, in which there is, in fact, no n_vclocks test: ptp_clock_adjtime() -> ptp_clock_freerun() -> ptp_vclock_in_use() The result is that any clock adjustment on any physical clock is now impossible. This is _despite_ there not being any vclock over this physical clock. $ ptp4l -i eno0 -2 -P -m ptp4l[58.425]: selected /dev/ptp0 as PTP clock [ 58.429749] ptp: physical clock is free running ptp4l[58.431]: Failed to open /dev/ptp0: Device or resource busy failed to create a clock $ cat /sys/class/ptp/ptp0/n_vclocks 0 The patch makes the ptp_vclock_in_use() function say "if it's not a virtual clock, then this physical clock does have virtual clocks on top". Then ptp_clock_freerun() uses this information to say "this physical clock has virtual clocks on top, so it must stay free-running". Then ptp_clock_adjtime() uses this information to say "well, if this physical clock has to be free-running, I can't do it, return -EBUSY". Simply put, ptp_vclock_in_use() cannot be simplified so as to remove the test whether vclocks are in use. What did the blamed commit intend to fix ---------------------------------------- The blamed commit presents a lockdep warning stating "possible recursive locking detected", with the n_vclocks_store() and ptp_clock_unregister() functions involved. The recursive locking seems this: n_vclocks_store() -> mutex_lock_interruptible(&ptp->n_vclocks_mux) // 1 -> device_for_each_child_reverse(..., unregister_vclock) -> unregister_vclock() -> ptp_vclock_unregister() -> ptp_clock_unregister() -> ptp_vclock_in_use() -> mutex_lock_interruptible(&ptp->n_vclocks_mux) // 2 The issue can be triggered by creating and then deleting vclocks: $ echo 2 > /sys/class/ptp/ptp0/n_vclocks $ echo 0 > /sys/class/ptp/ptp0/n_vclocks But note that in the original stack trace, the address of the first lock is different from the address of the second lock. This is because at step 1 marked above, &ptp->n_vclocks_mux is the lock of the parent (physical) PTP clock, and at step 2, the lock is of the child (virtual) PTP clock. They are different locks of different devices. In this situation there is no real deadlock, the lockdep warning is caused by the fact that the mutexes have the same lock class on both the parent and the child. Functionally it is fine. Proposed alternative solution ----------------------------- We must reintroduce the body of ptp_vclock_in_use() mostly as it was structured prior to the blamed commit, but avoid the lockdep warning. Based on the fact that vclocks cannot be nested on top of one another (ptp_is_attribute_visible() hides n_vclocks for virtual clocks), we already know that ptp->n_vclocks is zero for a virtual clock. And ptp->is_virtual_clock is a runtime invariant, established at ptp_clock_register() time and never changed. There is no need to serialize on any mutex in order to read ptp->is_virtual_clock, and we take advantage of that by moving it outside the lock. Thus, virtual clocks do not need to acquire &ptp->n_vclocks_mux at all, and step 2 in the code walkthrough above can simply go away. We can simply return false to the question "ptp_vclock_in_use(a virtual clock)". Other notes ----------- Releasing &ptp->n_vclocks_mux before ptp_vclock_in_use() returns execution seems racy, because the returned value can become stale as soon as the function returns and before the return value is used (i.e. n_vclocks_store() can run any time). The locking requirement should somehow be transferred to the caller, to ensure a longer life time for the returned value, but this seems out of scope for this severe bug fix. Because we are also fixing up the logic from the original commit, there is another Fixes: tag for that. Fixes: 87f7ce260a3c ("ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()") Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250613174749.406826-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b522158489778ef3129bed865dec4bf247593ca1 Author: Krishna Kumar Date: Tue May 20 22:36:56 2025 +0530 net: ice: Perform accurate aRFS flow match [ Upstream commit 5d3bc9e5e725aa36cca9b794e340057feb6880b4 ] This patch fixes an issue seen in a large-scale deployment under heavy incoming pkts where the aRFS flow wrongly matches a flow and reprograms the NIC with wrong settings. That mis-steering causes RX-path latency spikes and noisy neighbor effects when many connections collide on the same hash (some of our production servers have 20-30K connections). set_rps_cpu() calls ndo_rx_flow_steer() with flow_id that is calculated by hashing the skb sized by the per rx-queue table size. This results in multiple connections (even across different rx-queues) getting the same hash value. The driver steer function modifies the wrong flow to use this rx-queue, e.g.: Flow#1 is first added: Flow#1: , Hash 'h', q#10 Later when a new flow needs to be added: Flow#2: , Hash 'h', q#20 The driver finds the hash 'h' from Flow#1 and updates it to use q#20. This results in both flows getting un-optimized - packets for Flow#1 goes to q#20, and then reprogrammed back to q#10 later and so on; and Flow #2 programming is never done as Flow#1 is matched first for all misses. Many flows may wrongly share the same hash and reprogram rules of the original flow each with their own q#. Tested on two 144-core servers with 16K netperf sessions for 180s. Netperf clients are pinned to cores 0-71 sequentially (so that wrong packets on q#s 72-143 can be measured). IRQs are set 1:1 for queues -> CPUs, enable XPS, enable aRFS (global value is 144 * rps_flow_cnt). Test notes about results from ice_rx_flow_steer(): --------------------------------------------------- 1. "Skip:" counter increments here: if (fltr_info->q_index == rxq_idx || arfs_entry->fltr_state != ICE_ARFS_ACTIVE) goto out; 2. "Add:" counter increments here: ret = arfs_entry->fltr_info.fltr_id; INIT_HLIST_NODE(&arfs_entry->list_entry); 3. "Update:" counter increments here: /* update the queue to forward to on an already existing flow */ Runtime comparison: original code vs with the patch for different rps_flow_cnt values. +-------------------------------+--------------+--------------+ | rps_flow_cnt | 512 | 2048 | +-------------------------------+--------------+--------------+ | Ratio of Pkts on Good:Bad q's | 214 vs 822K | 1.1M vs 980K | | Avoid wrong aRFS programming | 0 vs 310K | 0 vs 30K | | CPU User | 216 vs 183 | 216 vs 206 | | CPU System | 1441 vs 1171 | 1447 vs 1320 | | CPU Softirq | 1245 vs 920 | 1238 vs 961 | | CPU Total | 29 vs 22.7 | 29 vs 24.9 | | aRFS Update | 533K vs 59 | 521K vs 32 | | aRFS Skip | 82M vs 77M | 7.2M vs 4.5M | +-------------------------------+--------------+--------------+ A separate TCP_STREAM and TCP_RR with 1,4,8,16,64,128,256,512 connections showed no performance degradation. Some points on the patch/aRFS behavior: 1. Enabling full tuple matching ensures flows are always correctly matched, even with smaller hash sizes. 2. 5-6% drop in CPU utilization as the packets arrive at the correct CPUs and fewer calls to driver for programming on misses. 3. Larger hash tables reduces mis-steering due to more unique flow hashes, but still has clashes. However, with larger per-device rps_flow_cnt, old flows take more time to expire and new aRFS flows cannot be added if h/w limits are reached (rps_may_expire_flow() succeeds when 10*rps_flow_cnt pkts have been processed by this cpu that are not part of the flow). Fixes: 28bf26724fdb0 ("ice: Implement aRFS") Signed-off-by: Krishna Kumar Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ef0b5bbbed7f220db2e9c73428f9a36e8dfc69ca Author: Justin Sanders Date: Tue Jun 10 17:05:59 2025 +0000 aoe: clean device rq_list in aoedev_downdev() [ Upstream commit 7f90d45e57cb2ef1f0adcaf925ddffdfc5e680ca ] An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=212665 Fixes: 3582dd291788 ("aoe: convert aoeblk to blk-mq") Signed-off-by: Justin Sanders Link: https://lore.kernel.org/r/20250610170600.869-1-jsanders.devel@gmail.com Tested-By: Valentin Kleibel Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f90220fc4a5f6ab5bb2b6ad181018db06a0c068a Author: Simon Horman Date: Fri Jun 13 17:46:20 2025 +0100 pldmfw: Select CRC32 when PLDMFW is selected [ Upstream commit 1224b218a4b9203656ecc932152f4c81a97b4fcc ] pldmfw calls crc32 code and depends on it being enabled, else there is a link error as follows. So PLDMFW should select CRC32. lib/pldmfw/pldmfw.o: In function `pldmfw_flash_image': pldmfw.c:(.text+0x70f): undefined reference to `crc32_le_base' This problem was introduced by commit b8265621f488 ("Add pldmfw library for PLDM firmware update"). It manifests as of commit d69ea414c9b4 ("ice: implement device flash update via devlink"). And is more likely to occur as of commit 9ad19171b6d6 ("lib/crc: remove unnecessary prompt for CONFIG_CRC32 and drop 'default y'"). Found by chance while exercising builds based on tinyconfig. Fixes: b8265621f488 ("Add pldmfw library for PLDM firmware update") Signed-off-by: Simon Horman Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250613-pldmfw-crc32-v1-1-f3fad109eee6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef3f3face5d0415153dca15ae92f273a4f98fae6 Author: Arnd Bergmann Date: Tue Jun 10 11:25:49 2025 +0200 hwmon: (occ) fix unaligned accesses [ Upstream commit 2c021b45c154958566aad0cae9f74ab26a2d5732 ] Passing a pointer to an unaligned integer as a function argument is undefined behavior: drivers/hwmon/occ/common.c:492:27: warning: taking address of packed member 'accumulator' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 492 | val = occ_get_powr_avg(&power->accumulator, | ^~~~~~~~~~~~~~~~~~ drivers/hwmon/occ/common.c:493:13: warning: taking address of packed member 'update_tag' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 493 | &power->update_tag); | ^~~~~~~~~~~~~~~~~ Move the get_unaligned() calls out of the function and pass these through argument registers instead. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250610092553.2641094-1-arnd@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit a5537ce4a98a24413bda1d60d3b5056c9fba9f3a Author: Arnd Bergmann Date: Tue Jun 10 11:23:06 2025 +0200 hwmon: (occ) Rework attribute registration for stack usage [ Upstream commit 744c2fe950e936c4d62430de899d6253424200ed ] clang produces an output with excessive stack usage when building the occ_setup_sensor_attrs() function, apparently the result of having a lot of struct literals and building with the -fno-strict-overflow option that leads clang to skip some optimization in case the 'attr' pointer overruns: drivers/hwmon/occ/common.c:775:12: error: stack frame size (1392) exceeds limit (1280) in 'occ_setup_sensor_attrs' [-Werror,-Wframe-larger-than] Replace the custom macros for initializing the attributes with a simpler function call that does not run into this corner case. Link: https://godbolt.org/z/Wf1Yx76a5 Fixes: 54076cb3b5ff ("hwmon (occ): Add sensor attributes and register hwmon device") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250610092315.2640039-1-arnd@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6e757e3c572806221a9543fff9cea3b42c1def5d Author: Eddie James Date: Tue Feb 15 09:10:22 2022 -0600 hwmon: (occ) Add soft minimum power cap attribute [ Upstream commit 84dc9e8a7eec2cdff00728baedf0fb35fc7c11e8 ] Export the power caps data for the soft minimum power cap through hwmon. Signed-off-by: Eddie James Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20220215151022.7498-5-eajames@linux.ibm.com Signed-off-by: Guenter Roeck Stable-dep-of: 744c2fe950e9 ("hwmon: (occ) Rework attribute registration for stack usage") Signed-off-by: Sasha Levin commit f4999111956a5018630e9ff62623e3260d51fd03 Author: Jacob Keller Date: Tue Jun 10 14:54:51 2025 -0700 drm/nouveau/bl: increase buffer size to avoid truncate warning [ Upstream commit 61b2b3737499f1fb361a54a16828db24a8345e85 ] The nouveau_get_backlight_name() function generates a unique name for the backlight interface, appending an id from 1 to 99 for all backlight devices after the first. GCC 15 (and likely other compilers) produce the following -Wformat-truncation warning: nouveau_backlight.c: In function ‘nouveau_backlight_init’: nouveau_backlight.c:56:69: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 3 [-Werror=format-truncation=] 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~ In function ‘nouveau_get_backlight_name’, inlined from ‘nouveau_backlight_init’ at nouveau_backlight.c:351:7: nouveau_backlight.c:56:56: note: directive argument in the range [1, 2147483647] 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~~~~~~~~~~~~~~~ nouveau_backlight.c:56:17: note: ‘snprintf’ output between 14 and 23 bytes into a destination of size 15 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The warning started appearing after commit ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()") This fix for the ida usage removed the explicit value check for ids larger than 99. The compiler is unable to intuit that the ida_alloc_max() limits the returned value range between 0 and 99. Because the compiler can no longer infer that the number ranges from 0 to 99, it thinks that it could use as many as 11 digits (10 + the potential - sign for negative numbers). The warning has gone unfixed for some time, with at least one kernel test robot report. The code breaks W=1 builds, which is especially frustrating with the introduction of CONFIG_WERROR. The string is stored temporarily on the stack and then copied into the device name. Its not a big deal to use 11 more bytes of stack rounding out to an even 24 bytes. Increase BL_NAME_SIZE to 24 to avoid the truncation warning. This fixes the W=1 builds that include this driver. Compile tested only. Fixes: ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312050324.0kv4PnfZ-lkp@intel.com/ Suggested-by: Timur Tabi Signed-off-by: Jacob Keller Link: https://lore.kernel.org/r/20250610-jk-nouveua-drm-bl-snprintf-fix-v2-1-7fdd4b84b48e@intel.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 3fc1401476cbc4c9b25d004c479639e54f62c167 Author: Krzysztof Kozlowski Date: Tue May 20 13:13:26 2025 +0200 drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate [ Upstream commit 8a48e35becb214743214f5504e726c3ec131cd6d ] Driver unconditionally saves current state on first init in dsi_pll_10nm_init(), but does not save the VCO rate, only some of the divider registers. The state is then restored during probe/enable via msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() -> dsi_10nm_pll_restore_state(). Restoring calls dsi_pll_10nm_vco_set_rate() with pll_10nm->vco_current_rate=0, which basically overwrites existing rate of VCO and messes with clock hierarchy, by setting frequency to 0 to clock tree. This makes anyway little sense - VCO rate was not saved, so should not be restored. If PLL was not configured configure it to minimum rate to avoid glitches and configuring entire in clock hierarchy to 0 Hz. Suggested-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/sz4kbwy5nwsebgf64ia7uq4ee7wbsa5uy3xmlqwcstsbntzcov@ew3dcyjdzmi2/ Signed-off-by: Krzysztof Kozlowski Fixes: a4ccc37693a2 ("drm/msm/dsi_pll_10nm: restore VCO rate during Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/654796/ Link: https://lore.kernel.org/r/20250520111325.92352-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 760e9efae70f9153a6720f05ab73f19ca138d66f Author: Gao Xiang Date: Tue Jun 17 13:40:56 2025 +0800 erofs: remove unused trace event erofs_destroy_inode commit 30b58444807c93bffeaba7d776110f2a909d2f9a upstream. The trace event `erofs_destroy_inode` was added but remains unused. This unused event contributes approximately 5KB to the kernel module size. Reported-by: Steven Rostedt Closes: https://lore.kernel.org/r/20250612224906.15000244@batman.local.home Fixes: 13f06f48f7bf ("staging: erofs: support tracepoint") Cc: stable@vger.kernel.org Reviewed-by: Hongbo Li Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20250617054056.3232365-1-hsiangkao@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit a3d864c901a300c295692d129159fc3001a56185 Author: Jann Horn Date: Tue May 27 23:23:54 2025 +0200 mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race commit 1013af4f585fccc4d3e5c5824d174de2257f7d6d upstream. huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse. Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-2-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250527-hugetlb-fixes-splitrace-v1-2-f4136f5ec58a@google.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Jann Horn Reviewed-by: Lorenzo Stoakes Cc: Liam Howlett Cc: Muchun Song Cc: Oscar Salvador Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman commit 8410996eb6fea116fe1483ed977aacf580eee7b4 Author: Liu Shixin Date: Mon Dec 16 15:11:47 2024 +0800 mm: hugetlb: independent PMD page table shared count commit 59d9094df3d79443937add8700b2ef1a866b1081 upstream. The folio refcount may be increased unexpectly through try_get_folio() by caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared. The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 The issue may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table. 1. The page table itself will be discarded after reporting the "nonzero mapcount". 2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped. Fix it by introducing independent PMD page table shared count. As described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv pmds, so we can reuse the field as pt_share_count. Link: https://lkml.kernel.org/r/20241216071147.3984217-1-liushixin2@huawei.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Liu Shixin Cc: Kefeng Wang Cc: Ken Chen Cc: Muchun Song Cc: Nanyong Sun Cc: Jane Chu Cc: Signed-off-by: Andrew Morton [backport note: struct ptdesc did not exist yet, stuff it equivalently into struct page instead] Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman commit 366298f2b04d2bf1f2f2b7078405bdf9df9bd5d0 Author: Jann Horn Date: Tue May 27 23:23:53 2025 +0200 mm/hugetlb: unshare page tables during VMA split, not before commit 081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0 upstream. Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2] Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-1-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-0-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250527-hugetlb-fixes-splitrace-v1-1-f4136f5ec58a@google.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Jann Horn Cc: Liam Howlett Reviewed-by: Lorenzo Stoakes Reviewed-by: Oscar Salvador Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: [b30c14cd6102: hugetlb: unshare some PMDs when splitting VMAs] Cc: Signed-off-by: Andrew Morton [stable backport: code got moved around, VMA splitting is in __vma_adjust, hugetlb lock wasn't used back then] Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman commit 37d49f91e523e5730e9d1302801434a51e036d10 Author: Sean Nyekjaer Date: Mon May 5 21:20:07 2025 +0200 iio: accel: fxls8962af: Fix temperature calculation commit 16038474e3a0263572f36326ef85057aaf341814 upstream. According to spec temperature should be returned in milli degrees Celsius. Add in_temp_scale to calculate from Celsius to milli Celsius. Fixes: a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers") Cc: stable@vger.kernel.org Reviewed-by: Marcelo Schmitt Signed-off-by: Sean Nyekjaer Link: https://patch.msgid.link/20250505-fxls-v4-1-a38652e21738@geanix.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8f5fcf574eedeccff85fadf0d6873f36e3fb8c24 Author: Jonathan Lane Date: Wed Jun 11 12:31:25 2025 -0700 ALSA: hda/realtek: enable headset mic on Latitude 5420 Rugged commit efa6bdf1bc75e26cafaa5f1d775e8bb7c5b0c431 upstream. Like many Dell laptops, the 3.5mm port by default can not detect a combined headphones+mic headset or even a pure microphone. This change enables the port's functionality. Signed-off-by: Jonathan Lane Cc: Link: https://patch.msgid.link/20250611193124.26141-2-jon@borg.moe Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 639b31e3885365c6992bc6d58b9adf4accebf4bb Author: Takashi Iwai Date: Sun Jun 8 11:14:14 2025 +0200 ALSA: hda/intel: Add Thinkpad E15 to PM deny list commit c987a390f1b3b8bdac11031d7004e3410fe259bd upstream. Lenovo Thinkpad E15 with Conexant CX8070 codec seems causing ugly noises after runtime-PM suspend. Disable the codec runtime PM as a workaround. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220210 Cc: Link: https://patch.msgid.link/20250608091415.21170-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a8aec0d35e938a5180ff76e355f356d4f71ef0bb Author: wangdicheng Date: Fri Jun 13 14:36:36 2025 +0800 ALSA: usb-audio: Rename ALSA kcontrol PCM and PCM1 for the KTMicro sound card commit 93adf20ff4d6e865e0b974110d3cf2f07c057177 upstream. PCM1 not in Pulseaudio's control list; standardize control to "Speaker" and "Headphone". Signed-off-by: wangdicheng Cc: Link: https://patch.msgid.link/20250613063636.239683-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a4a4abc818de66a5bcb3c89f23425925b9ddbce5 Author: WangYuli Date: Fri Apr 18 18:37:18 2025 -0700 Input: sparcspkr - avoid unannotated fall-through commit 8b1d858cbd4e1800e9336404ba7892b5a721230d upstream. Fix follow warnings with clang-21i (and reformat for clarity): drivers/input/misc/sparcspkr.c:78:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] 78 | case SND_TONE: break; | ^ drivers/input/misc/sparcspkr.c:78:3: note: insert 'break;' to avoid fall-through 78 | case SND_TONE: break; | ^ | break; drivers/input/misc/sparcspkr.c:113:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] 113 | case SND_TONE: break; | ^ drivers/input/misc/sparcspkr.c:113:3: note: insert 'break;' to avoid fall-through 113 | case SND_TONE: break; | ^ | break; 2 warnings generated. Signed-off-by: WangYuli Link: https://lore.kernel.org/r/6730E40353C76908+20250415052439.155051-1-wangyuli@uniontech.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit add2a8e193f371fef6b2f8b785dd9e5aa04df729 Author: Christoph Hellwig Date: Fri Feb 25 19:14:40 2022 +0100 block: default BLOCK_LEGACY_AUTOLOAD to y commit 451f0b6f4c44d7b649ae609157b114b71f6d7875 upstream. As Luis reported, losetup currently doesn't properly create the loop device without this if the device node already exists because old scripts created it manually. So default to y for now and remove the aggressive removal schedule. Reported-by: Luis Chamberlain Signed-off-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20220225181440.1351591-1-hch@lst.de Signed-off-by: Jens Axboe Cc: Sebastian Priebe Link: https://lore.kernel.org/r/ZR0P278MB097497EF6CFD85E72819447E9F70A@ZR0P278MB0974.CHEP278.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman commit 1df80d748f984290c895e843401824215dcfbfb0 Author: Terry Junge Date: Wed Mar 12 15:23:31 2025 -0700 HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() commit fe7f7ac8e0c708446ff017453add769ffc15deed upstream. Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors. Reported-by: syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c52569baf0c843f35495 Fixes: f043bfc98c19 ("HID: usbhid: fix out-of-bounds bug") Cc: stable@vger.kernel.org Signed-off-by: Terry Junge Reviewed-by: Michael Kelley Signed-off-by: Jiri Kosina Signed-off-by: Terry Junge Signed-off-by: Greg Kroah-Hartman commit 287b4f085d2ca3375cf1ee672af27410c64777e8 Author: Kuniyuki Iwashima Date: Mon Jun 16 11:21:15 2025 -0700 atm: Revert atm_account_tx() if copy_from_iter_full() fails. commit 7851263998d4269125fd6cb3fdbfc7c6db853859 upstream. In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx(). It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb). However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket. Let's factorise the revert part as atm_return_tx() and call it in the failure path. Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20250614161959.GR414686@horms.kernel.org/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250616182147.963333-3-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6500f360a435256e77a5ee8792db81c86438bc97 Author: Stephen Smalley Date: Fri Jun 13 15:37:05 2025 -0400 selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len commit 86c8db86af43f52f682e53a0f2f0828683be1e52 upstream. We should count the terminating NUL byte as part of the ctx_len. Otherwise, UBSAN logs a warning: UBSAN: array-index-out-of-bounds in security/selinux/xfrm.c:99:14 index 60 is out of range for type 'char [*]' The allocation itself is correct so there is no actual out of bounds indexing, just a warning. Cc: stable@vger.kernel.org Suggested-by: Christian Göttsche Link: https://lore.kernel.org/selinux/CAEjxPJ6tA5+LxsGfOJokzdPeRomBHjKLBVR6zbrg+_w3ZZbM3A@mail.gmail.com/ Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 06780dbaa92921a82f9257b8f173c19304375195 Author: Xin Li (Intel) Date: Mon Jun 9 01:40:54 2025 -0700 selftests/x86: Add a test to detect infinite SIGTRAP handler loop commit f287822688eeb44ae1cf6ac45701d965efc33218 upstream. When FRED is enabled, if the Trap Flag (TF) is set without an external debugger attached, it can lead to an infinite loop in the SIGTRAP handler. To avoid this, the software event flag in the augmented SS must be cleared, ensuring that no single-step trap remains pending when ERETU completes. This test checks for that specific scenario—verifying whether the kernel correctly prevents an infinite SIGTRAP loop in this edge case when FRED is enabled. The test should _always_ pass with IDT event delivery, thus no need to disable the test even when FRED is not enabled. Signed-off-by: Xin Li (Intel) Signed-off-by: Dave Hansen Tested-by: Sohil Mehta Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-3-xin%40zytor.com Signed-off-by: Greg Kroah-Hartman commit 9d83ca27a6343849ad5f332ae3b9ef9890fb1e69 Author: Marek Szyprowski Date: Wed May 7 18:09:12 2025 +0200 udmabuf: use sgtable-based scatterlist wrappers commit afe382843717d44b24ef5014d57dcbaab75a4052 upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgtable's nents. Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access") CC: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Acked-by: Vivek Kasireddy Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20250507160913.2084079-3-m.szyprowski@samsung.com Signed-off-by: Greg Kroah-Hartman commit 3f6e9a24abeb01db5d3afe1e285476f5732724c5 Author: Peter Oberparleiter Date: Tue Jun 3 20:21:56 2025 +0200 scsi: s390: zfcp: Ensure synchronous unit_add commit 9697ca0d53e3db357be26d2414276143c4a2cd49 upstream. Improve the usability of the unit_add sysfs attribute by ensuring that the associated FCP LUN scan processing is completed synchronously. This enables configuration tooling to consistently determine the end of the scan process to allow for serialization of follow-on actions. While the scan process associated with unit_add typically completes synchronously, it is deferred to an asynchronous background process if unit_add is used before initial remote port scanning has completed. This occurs when unit_add is used immediately after setting the associated FCP device online. To ensure synchronous unit_add processing, wait for remote port scanning to complete before initiating the FCP LUN scan. Cc: stable@vger.kernel.org Reviewed-by: M Nikhil Reviewed-by: Nihar Panda Signed-off-by: Peter Oberparleiter Signed-off-by: Nihar Panda Link: https://lore.kernel.org/r/20250603182252.2287285-2-niharp@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f65f2291e7953d2656e3b8849254d04c940c705e Author: Dexuan Cui Date: Fri Jun 6 13:57:39 2025 -0700 scsi: storvsc: Increase the timeouts to storvsc_timeout commit b2f966568faaad326de97481096d0f3dc0971c43 upstream. Currently storvsc_timeout is only used in storvsc_sdev_configure(), and 5s and 10s are used elsewhere. It turns out that rarely the 5s is not enough on Azure, so let's use storvsc_timeout everywhere. In case a timeout happens and storvsc_channel_init() returns an error, close the VMBus channel so that any host-to-guest messages in the channel's ringbuffer, which might come late, can be safely ignored. Add a "const" to storvsc_timeout. Cc: stable@kernel.org Signed-off-by: Dexuan Cui Link: https://lore.kernel.org/r/1749243459-10419-1-git-send-email-decui@microsoft.com Reviewed-by: Long Li Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f41c625328777f9ad572901ba0b0065bb9c9c1da Author: Fedor Pchelkin Date: Tue Mar 25 19:32:13 2025 +0300 jffs2: check jffs2_prealloc_raw_node_refs() result in few other places commit 2b6d96503255a3ed676cd70f8368870c6d6a25c6 upstream. Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 2f785402f39b ("[JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code.") Fixes: f560928baa60 ("[JFFS2] Allocate node_ref for wasted space when skipping to page boundary") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 4adee34098a6ee86a54bf3ec885eab620c126a6b Author: Artem Sadovnikov Date: Fri Mar 7 16:34:09 2025 +0000 jffs2: check that raw node were preallocated before writing summary commit ec9e6f22bce433b260ea226de127ec68042849b0 upstream. Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node. kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: jffs2_sum_write_data fs/jffs2/summary.c:841 [inline] jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005 call_write_iter include/linux/fs.h:2265 [inline] do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10c/0x170 fs/splice.c:950 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 2f785402f39b ("[JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code.") Signed-off-by: Artem Sadovnikov Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 58f664614f8c3d6142ab81ae551e466dc6e092e8 Author: Andrew Morton Date: Sat Jun 7 17:43:18 2025 -0700 drivers/rapidio/rio_cm.c: prevent possible heap overwrite commit 50695153d7ddde3b1696dbf0085be0033bf3ddb3 upstream. In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. Reported-by: maher azz Cc: Matt Porter Cc: Alexandre Bounine Cc: Linus Torvalds Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a41f447cb27a1985c17cadc57883966a6b53dd6a Author: Breno Leitao Date: Fri Jun 20 06:51:23 2025 -0700 Revert "x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2" on v6.6 and older This reverts commit 4fc2d289b3cc4cf23ccabe59cf936d1dc49aeda8 which is commit 98fdaeb296f51ef08e727a7cc72e5b5c864c4f4d upstream. commit 7adb96687ce8 ("x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2") depends on commit 72c70f480a70 ("x86/bugs: Add a separate config for Spectre V2"), which introduced MITIGATION_SPECTRE_V2. commit 72c70f480a70 ("x86/bugs: Add a separate config for Spectre V2") never landed in stable tree, thus, stable tree doesn't have MITIGATION_SPECTRE_V2, that said, commit 7adb96687ce8 ("x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2") has no value if the dependecy was not applied. Revert commit 7adb96687ce8 ("x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2") in stable kernel which landed in in 5.4.294, 5.10.238, 5.15.185, 6.1.141 and 6.6.93 stable versions. Cc: David.Kaplan@amd.com Cc: peterz@infradead.org Cc: pawan.kumar.gupta@linux.intel.com Cc: mingo@kernel.org Cc: brad.spengler@opensrcsec.com Cc: stable@vger.kernel.org # 6.6 6.1 5.15 5.10 5.4 Reported-by: Brad Spengler Reported-by: Salvatore Bonaccorso Signed-off-by: Breno Leitao Signed-off-by: Greg Kroah-Hartman commit 96baba48722b9ddb03b1fc54bcde80a5bc40daa1 Author: Narayana Murty N Date: Thu May 8 02:29:28 2025 -0400 powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH recovery [ Upstream commit 33bc69cf6655cf60829a803a45275f11a74899e5 ] VFIO EEH recovery for PCI passthrough devices fails on PowerNV and pseries platforms due to missing host-side PE bridge reconfiguration. In the current implementation, eeh_pe_configure() only performs RTAS or OPAL-based bridge reconfiguration for native host devices, but skips it entirely for PEs managed through VFIO in guest passthrough scenarios. This leads to incomplete EEH recovery when a PCI error affects a passthrough device assigned to a QEMU/KVM guest. Although VFIO triggers the EEH recovery flow through VFIO_EEH_PE_ENABLE ioctl, the platform-specific bridge reconfiguration step is silently bypassed. As a result, the PE's config space is not fully restored, causing subsequent config space access failures or EEH freeze-on-access errors inside the guest. This patch fixes the issue by ensuring that eeh_pe_configure() always invokes the platform's configure_bridge() callback (e.g., pseries_eeh_phb_configure_bridge) even for VFIO-managed PEs. This ensures that RTAS or OPAL calls to reconfigure the PE bridge are correctly issued on the host side, restoring the PE's configuration space after an EEH event. This fix is essential for reliable EEH recovery in QEMU/KVM guests using VFIO PCI passthrough on PowerNV and pseries systems. Tested with: - QEMU/KVM guest using VFIO passthrough (IBM Power9,(lpar)Power11 host) - Injected EEH errors with pseries EEH errinjct tool on host, recovery verified on qemu guest. - Verified successful config space access and CAP_EXP DevCtl restoration after recovery Fixes: 212d16cdca2d ("powerpc/eeh: EEH support for VFIO PCI device") Signed-off-by: Narayana Murty N Reviewed-by: Vaibhav Jain Reviewed-by: Ganesh Goudar Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250508062928.146043-1-nnmlinux@linux.ibm.com Signed-off-by: Sasha Levin commit 25375f0d0b6caa815c072ddb10528523d1a84348 Author: Stuart Hayes Date: Mon Jun 9 13:46:58 2025 -0500 platform/x86: dell_rbu: Stop overwriting data buffer [ Upstream commit f4b0fa38d5fefe9aed6ed831f3bd3538c168ee19 ] The dell_rbu driver will use memset() to clear the data held by each packet when it is no longer needed (when the driver is unloaded, the packet size is changed, etc). The amount of memory that is cleared (before this patch) is the normal packet size. However, the last packet in the list may be smaller. Fix this to only clear the memory actually used by each packet, to prevent it from writing past the end of data buffer. Because the packet data buffers are allocated with __get_free_pages() (in page-sized increments), this bug could only result in a buffer being overwritten when a packet size larger than one page is used. The only user of the dell_rbu module should be the Dell BIOS update program, which uses a packet size of 4096, so no issues should be seen without the patch, it just blocks the possiblity. Fixes: 6c54c28e69f2 ("[PATCH] dell_rbu: new Dell BIOS update driver") Signed-off-by: Stuart Hayes Link: https://lore.kernel.org/r/20250609184659.7210-5-stuart.w.hayes@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 07d7b8e7ef7d1f812a6211ed531947c56d09e95e Author: Stuart Hayes Date: Mon Jun 9 13:46:56 2025 -0500 platform/x86: dell_rbu: Fix list usage [ Upstream commit 61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 ] Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference. Fixes: d19f359fbdc6 ("platform/x86: dell_rbu: don't open code list_for_each_entry*()") Signed-off-by: Stuart Hayes Link: https://lore.kernel.org/r/20250609184659.7210-3-stuart.w.hayes@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit b90dd5b12152335b9cb95a560be683606c878e0d Author: Alexander Sverdlin Date: Tue Apr 1 11:06:34 2025 +0200 Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first" [ Upstream commit 36305857b1ead8f6ca033a913162ebc09bee0b43 ] This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. It breaks target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case when minimally-configured system tries to network-boot: [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) [ 26.878471] Waiting up to 100 more seconds for network. There are minimal configurations possible when the deferred device is not being probed any more (because everything else has been successfully probed) and deferral lists are not processed any more. Stable mmc enumeration can be achieved by filling /aliases node properly (4700a00755fb commit's rationale). After revert: [ 9.006816] IP-Config: Complete: [ 9.010058] device=lan0, ... Tested-by: Andreas Kemnade # GTA04, Panda, BT200 Reviewed-by: Tony Lindgren Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250401090643.2776793-1-alexander.sverdlin@siemens.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit dd89a7e18c9cd06e35548643af0eee4bb1b85e1e Author: Jann Horn Date: Mon Apr 28 15:06:43 2025 +0200 tee: Prevent size calculation wraparound on 32-bit kernels [ Upstream commit 39bb67edcc582b3b386a9ec983da67fa8a10ec03 ] The current code around TEE_IOCTL_PARAM_SIZE() is a bit wrong on 32-bit kernels: Multiplying a user-provided 32-bit value with the size of a structure can wrap around on such platforms. Fix it by using saturating arithmetic for the size calculation. This has no security consequences because, in all users of TEE_IOCTL_PARAM_SIZE(), the subsequent kcalloc() implicitly checks for wrapping. Signed-off-by: Jann Horn Signed-off-by: Jens Wiklander Tested-by: Rouven Czerwinski Signed-off-by: Sasha Levin commit a5cc6ccac4d95ccd132ca19d6d336a0e4a4b6874 Author: Sukrut Bellary Date: Tue Mar 18 16:00:39 2025 -0700 ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY [ Upstream commit 47fe74098f3dadba2f9cc1e507d813a4aa93f5f3 ] Don't put the l4ls clk domain to sleep in case of standby. Since CM3 PM FW[1](ti-v4.1.y) doesn't wake-up/enable the l4ls clk domain upon wake-up, CM3 PM FW fails to wake-up the MPU. [1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/ Signed-off-by: Sukrut Bellary Tested-by: Judith Mendez Link: https://lore.kernel.org/r/20250318230042.3138542-2-sbellary@baylibre.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 73f3d6261ac4fc7c1a58d6f324830d6a61cb8a76 Author: Laurentiu Tudor Date: Tue Apr 8 13:58:14 2025 +0300 bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value [ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ] In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough. Increase the timeout value so that we don't have any chance of wrongly assuming that the firmware is not responding when it's just taking more time. Signed-off-by: Laurentiu Tudor Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250408105814.2837951-7-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Sasha Levin commit 04584bba32499f51c0b6615b9d1c125c815d8a2c Author: Marcus Folkesson Date: Wed Mar 26 09:29:51 2025 +0100 watchdog: da9052_wdt: respect TWDMIN [ Upstream commit 325f510fcd9cda5a44bcb662b74ba4e3dabaca10 ] We have to wait at least the minimium time for the watchdog window (TWDMIN) before writings to the wdt register after the watchdog is activated. Otherwise the chip will assert TWD_ERROR and power down to reset mode. Signed-off-by: Marcus Folkesson Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250326-da9052-fixes-v3-4-a38a560fef0e@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 5e615cecf32eaae8cff239f30a72cf96f642e621 Author: Wentao Liang Date: Tue Apr 8 11:26:02 2025 +0800 octeontx2-pf: Add error log forcn10k_map_unmap_rq_policer() [ Upstream commit 9c056ec6dd1654b1420dafbbe2a69718850e6ff2 ] The cn10k_free_matchall_ipolicer() calls the cn10k_map_unmap_rq_policer() for each queue in a for loop without checking for any errors. Check the return value of the cn10k_map_unmap_rq_policer() function during each loop, and report a warning if the function fails. Signed-off-by: Wentao Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250408032602.2909-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5badeca146b24c449a67706e3d7e2c2801f1376a Author: Jiayuan Chen Date: Mon Apr 7 22:21:20 2025 +0800 bpf, sockmap: Fix data lost during EAGAIN retries [ Upstream commit 7683167196bd727ad5f3c3fc6a9ca70f54520a81 ] We call skb_bpf_redirect_clear() to clean _sk_redir before handling skb in backlog, but when sk_psock_handle_skb() return EAGAIN due to sk_rcvbuf limit, the redirect info in _sk_redir is not recovered. Fix skb redir loss during EAGAIN retries by restoring _sk_redir information using skb_bpf_set_redir(). Before this patch: ''' ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress Setting up benchmark 'sockmap'... create socket fd c1:13 p1:14 c2:15 p2:16 Benchmark 'sockmap' started. Send Speed 1343.172 MB/s, BPF Speed 1343.238 MB/s, Rcv Speed 65.271 MB/s Send Speed 1352.022 MB/s, BPF Speed 1352.088 MB/s, Rcv Speed 0 MB/s Send Speed 1354.105 MB/s, BPF Speed 1354.105 MB/s, Rcv Speed 0 MB/s Send Speed 1355.018 MB/s, BPF Speed 1354.887 MB/s, Rcv Speed 0 MB/s ''' Due to the high send rate, the RX processing path may frequently hit the sk_rcvbuf limit. Once triggered, incorrect _sk_redir will cause the flow to mistakenly enter the "!ingress" path, leading to send failures. (The Rcv speed depends on tcp_rmem). After this patch: ''' ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress Setting up benchmark 'sockmap'... create socket fd c1:13 p1:14 c2:15 p2:16 Benchmark 'sockmap' started. Send Speed 1347.236 MB/s, BPF Speed 1347.367 MB/s, Rcv Speed 65.402 MB/s Send Speed 1353.320 MB/s, BPF Speed 1353.320 MB/s, Rcv Speed 65.536 MB/s Send Speed 1353.186 MB/s, BPF Speed 1353.121 MB/s, Rcv Speed 65.536 MB/s ''' Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250407142234.47591-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fecb2fc3fc10c95724407cc45ea35af4a65cdde2 Author: Kyungwook Boo Date: Tue Mar 11 14:16:02 2025 +0900 i40e: fix MMIO write access to an invalid page in i40e_clear_hw [ Upstream commit 015bac5daca978448f2671478c553ce1f300c21e ] When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables. Signed-off-by: Kyungwook Boo Link: https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7095@gmail.com/T/ Reviewed-by: Przemek Kitszel Reviewed-by: Simon Horman Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cafc3c567e4e384830270f9ad859d592e69b7bec Author: Zijun Hu Date: Thu Apr 10 09:01:27 2025 +0800 sock: Correct error checking condition for (assign|release)_proto_idx() [ Upstream commit faeefc173be40512341b102cf1568aa0b6571acd ] (assign|release)_proto_idx() wrongly check find_first_zero_bit() failure by condition '(prot->inuse_idx == PROTO_INUSE_NR - 1)' obviously. Fix by correcting the condition to '(prot->inuse_idx == PROTO_INUSE_NR)' Signed-off-by: Zijun Hu Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250410-fix_net-v2-1-d69e7c5739a4@quicinc.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d34f2384d6df11a6c67039b612c2437f46e587e8 Author: Daniel Wagner Date: Wed Apr 9 13:34:22 2025 +0200 scsi: lpfc: Use memcpy() for BIOS version [ Upstream commit ae82eaf4aeea060bb736c3e20c0568b67c701d7d ] The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string. Signed-off-by: Daniel Wagner Link: https://lore.kernel.org/r/20250409-fix-lpfc-bios-str-v1-1-05dac9e51e13@kernel.org Reviewed-by: Justin Tee Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eb295874a43c584532c331f18c4e42b5e68afa09 Author: Mike Looijmans Date: Fri Mar 14 16:17:45 2025 +0100 pinctrl: mcp23s08: Reset all pins to input at probe [ Upstream commit 3ede3f8b4b4b399b0ca41e44959f80d5cf84fc98 ] At startup, the driver just assumes that all registers have their default values. But after a soft reset, the chip will just be in the state it was, and some pins may have been configured as outputs. Any modification of the output register will cause these pins to be driven low, which leads to unexpected/unwanted effects. To prevent this from happening, set the chip's IO configuration register to a known safe mode (all inputs) before toggling any other bits. Signed-off-by: Mike Looijmans Link: https://lore.kernel.org/20250314151803.28903-1-mike.looijmans@topic.nl Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 56ce76e8d406cc72b89aee7931df5cf3f18db49d Author: Zijun Hu Date: Mon Apr 14 19:36:52 2025 +0800 software node: Correct a OOB check in software_node_get_reference_args() [ Upstream commit 31e4e12e0e9609850cefd4b2e1adf782f56337d6 ] software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'. Reviewed-by: Sakari Ailus Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250414-fix_swnode-v2-1-9c9e6ae11eab@quicinc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d9513b4444683b7bf9836b25735720a7c770737 Author: Ido Schimmel Date: Tue Apr 15 15:11:41 2025 +0300 vxlan: Do not treat dst cache initialization errors as fatal [ Upstream commit 20c76dadc783759fd3819d289c72be590660cc8b ] FDB entries are allocated in an atomic context as they can be added from the data path when learning is enabled. After converting the FDB hash table to rhashtable, the insertion rate will be much higher (*) which will entail a much higher rate of per-CPU allocations via dst_cache_init(). When adding a large number of entries (e.g., 256k) in a batch, a small percentage (< 0.02%) of these per-CPU allocations will fail [1]. This does not happen with the current code since the insertion rate is low enough to give the per-CPU allocator a chance to asynchronously create new chunks of per-CPU memory. Given that: a. Only a small percentage of these per-CPU allocations fail. b. The scenario where this happens might not be the most realistic one. c. The driver can work correctly without dst caches. The dst_cache_*() APIs first check that the dst cache was properly initialized. d. The dst caches are not always used (e.g., 'tos inherit'). It seems reasonable to not treat these allocation failures as fatal. Therefore, do not bail when dst_cache_init() fails and suppress warnings by specifying '__GFP_NOWARN'. [1] percpu: allocation failed, size=40 align=8 atomic=1, atomic alloc failed, no space left (*) 97% reduction in average latency of vxlan_fdb_update() when adding 256k entries in a batch. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250415121143.345227-14-idosch@nvidia.com Reviewed-by: Nikolay Aleksandrov Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 410a033bfa8c7daefbae0225c836693db2149ec1 Author: Yong Wang Date: Thu Apr 17 15:43:12 2025 +0200 net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions [ Upstream commit 4b30ae9adb047dd0a7982975ec3933c529537026 ] When a bridge port STP state is changed from BLOCKING/DISABLED to FORWARDING, the port's igmp query timer will NOT re-arm itself if the bridge has been configured as per-VLAN multicast snooping. Solve this by choosing the correct multicast context(s) to enable/disable port multicast based on whether per-VLAN multicast snooping is enabled or not, i.e. using per-{port, VLAN} context in case of per-VLAN multicast snooping by re-implementing br_multicast_enable_port() and br_multicast_disable_port() functions. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang Reviewed-by: Andy Roulin Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c9bfb30b75c35b072f52f35ec4af3221addab855 Author: Sean Christopherson Date: Fri Mar 14 20:10:48 2025 -0700 iommu/amd: Ensure GA log notifier callbacks finish running before module unload [ Upstream commit 94c721ea03c7078163f41dbaa101ac721ddac329 ] Synchronize RCU when unregistering KVM's GA log notifier to ensure all in-flight interrupt handlers complete before KVM-the module is unloaded. Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20250315031048.2374109-1-seanjc@google.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7cf3c7bd83ee280662c96728424255aeac92e691 Author: Justin Tee Date: Fri Apr 25 12:47:59 2025 -0700 scsi: lpfc: Fix lpfc_check_sli_ndlp() handling for GEN_REQUEST64 commands [ Upstream commit 05ae6c9c7315d844fbc15afe393f5ba5e5771126 ] In lpfc_check_sli_ndlp(), the get_job_els_rsp64_did remote_id assignment does not apply for GEN_REQUEST64 commands as it only has meaning for a ELS_REQUEST64 command. So, if (iocb->ndlp == ndlp) is false, we could erroneously return the wrong value. Fix by replacing the fallthrough statement with a break statement before the remote_id check. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20250425194806.3585-2-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2fc2e9e865ccb6fdd9d62a373501c675804be009 Author: Alan Maguire Date: Tue Apr 29 17:10:42 2025 +0100 libbpf: Add identical pointer detection to btf_dedup_is_equiv() [ Upstream commit 8e64c387c942229c551d0f23de4d9993d3a2acb6 ] Recently as a side-effect of commit ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro") issues were observed in deduplication between modules and kernel BTF such that a large number of kernel types were not deduplicated so were found in module BTF (task_struct, bpf_prog etc). The root cause appeared to be a failure to dedup struct types, specifically those with members that were pointers with __percpu annotations. The issue in dedup is at the point that we are deduplicating structures, we have not yet deduplicated reference types like pointers. If multiple copies of a pointer point at the same (deduplicated) integer as in this case, we do not see them as identical. Special handling already exists to deal with structures and arrays, so add pointer handling here too. Reported-by: Alexei Starovoitov Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250429161042.2069678-1-alan.maguire@oracle.com Signed-off-by: Sasha Levin commit 59bbff4eedff7baa98bdc3655e99b45abb93ea50 Author: Heiko Stuebner Date: Sat May 3 22:25:31 2025 +0200 clk: rockchip: rk3036: mark ddrphy as critical [ Upstream commit 596a977b34a722c00245801a5774aa79cec4e81d ] The ddrphy is supplied by the dpll, but due to the limited number of PLLs on the rk3036, the dpll also is used for other periperhals, like the GPU. So it happened, when the Lima driver turned off the gpu clock, this in turn also disabled the dpll and thus the ram. Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250503202532.992033-4-heiko@sntech.de Signed-off-by: Sasha Levin commit d7ef254e72074b48b4d6cad5fa0b49d8b1566e3d Author: Benjamin Berg Date: Wed Apr 30 21:10:42 2025 +0200 wifi: mac80211: do not offer a mesh path if forwarding is disabled [ Upstream commit cf1b684a06170d253b47d6a5287821de976435bd ] When processing a PREQ the code would always check whether we have a mesh path locally and reply accordingly. However, when forwarding is disabled then we should not reply with this information as we will not forward data packets down that path. Move the check for dot11MeshForwarding up in the function and skip the mesh path lookup in that case. In the else block, set forward to false so that the rest of the function becomes a no-op and the dot11MeshForwarding check does not need to be duplicated. This explains an effect observed in the Freifunk community where mesh forwarding is disabled. In that case a mesh with three STAs and only bad links in between them, individual STAs would occionally have indirect mpath entries. This should not have happened. Signed-off-by: Benjamin Berg Reviewed-by: Rouven Czerwinski Link: https://patch.msgid.link/20250430191042.3287004-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0d4a81c341ebc10e8b0e45405702dadb296e8bbf Author: Jason Xing Date: Sat May 10 17:34:42 2025 +0800 net: mlx4: add SOF_TIMESTAMPING_TX_SOFTWARE flag when getting ts info [ Upstream commit b86bcfee30576b752302c55693fff97242b35dfd ] As mlx4 has implemented skb_tx_timestamp() in mlx4_en_xmit(), the SOFTWARE flag is surely needed when users are trying to get timestamp information. Signed-off-by: Jason Xing Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250510093442.79711-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4bcc11448b16e3a851e666b52ce7c2369a0a1289 Author: Gabor Juhos Date: Wed May 14 21:18:35 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get() [ Upstream commit 57273ff8bb16f3842c2597b5bbcd49e7fa12edf7 ] The regmap_read() function can fail, so propagate its error up to the stack instead of silently ignoring that. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-4-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c871d2b85c5715da9fd7f0399e06a07866efd02e Author: Gabor Juhos Date: Wed May 14 21:18:36 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_pmx_gpio_set_direction() [ Upstream commit bfa0ff804ffa8b1246ade8be08de98c9eb19d16f ] The armada_37xx_gpio_direction_{in,out}put() functions can fail, so propagate their error values back to the stack instead of silently ignoring those. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-5-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0245c91f4fdc2fc84e25c73f3bc8fd1acc7d5c47 Author: Gabor Juhos Date: Wed May 14 21:18:37 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get_direction() [ Upstream commit 6481c0a83367b0672951ccc876fbae7ee37b594b ] The regmap_read() function can fail, so propagate its error up to the stack instead of silently ignoring that. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-6-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 017035aaff2baf4c0667f86c6ad3d379a587d1ab Author: Gabor Juhos Date: Wed May 14 21:18:38 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_pmx_set_by_name() [ Upstream commit 4229c28323db141eda69cb99427be75d3edba071 ] The regmap_update_bits() function can fail, so propagate its error up to the stack instead of silently ignoring that. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-7-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fbab07112a9e1ce5ac052c7fac3a63bd4c49da48 Author: Jason Xing Date: Sat May 10 21:48:10 2025 +0800 net: atlantic: generate software timestamp just before the doorbell [ Upstream commit 285ad7477559b6b5ceed10ba7ecfed9d17c0e7c6 ] Make sure the call of skb_tx_timestamp is as close as possible to the doorbell. Signed-off-by: Jason Xing Link: https://patch.msgid.link/20250510134812.48199-2-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1ee5f16757a23161a7f5fecd4b7bb7778fa6772 Author: Sebastian Andrzej Siewior Date: Mon May 12 11:27:24 2025 +0200 ipv4/route: Use this_cpu_inc() for stats on PREEMPT_RT [ Upstream commit 1c0829788a6e6e165846b9bedd0b908ef16260b6 ] The statistics are incremented with raw_cpu_inc() assuming it always happens with bottom half disabled. Without per-CPU locking in local_bh_disable() on PREEMPT_RT this is no longer true. Use this_cpu_inc() on PREEMPT_RT for the increment to not worry about preemption. Cc: David Ahern Signed-off-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20250512092736.229935-4-bigeasy@linutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 97033659fc835e0e6531a0113b14c8394e7ef8a1 Author: Eric Dumazet Date: Tue May 13 19:39:14 2025 +0000 tcp: fix initial tp->rcvq_space.space value for passive TS enabled flows [ Upstream commit cd171461b90a2d2cf230943df60d580174633718 ] tcp_rcv_state_process() must tweak tp->advmss for TS enabled flows before the call to tcp_init_transfer() / tcp_init_buffer_space(). Otherwise tp->rcvq_space.space is off by 120 bytes (TCP_INIT_CWND * TCPOLEN_TSTAMP_ALIGNED). Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20250513193919.1089692-7-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a7d4705f60b64cd8644939d9233e88a3a85534ad Author: Eric Dumazet Date: Tue May 13 19:39:15 2025 +0000 tcp: always seek for minimal rtt in tcp_rcv_rtt_update() [ Upstream commit b879dcb1aeeca278eacaac0b1e2425b1c7599f9f ] tcp_rcv_rtt_update() goal is to maintain an estimation of the RTT in tp->rcv_rtt_est.rtt_us, used by tcp_rcv_space_adjust() When TCP TS are enabled, tcp_rcv_rtt_update() is using EWMA to smooth the samples. Change this to immediately latch the incoming value if it is lower than tp->rcv_rtt_est.rtt_us, so that tcp_rcv_space_adjust() does not overshoot tp->rcvq_space.space and sk->sk_rcvbuf. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250513193919.1089692-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8ce9d65726d58c1c3be573555f7d583417edd818 Author: Moon Yeounsu Date: Thu May 15 16:53:31 2025 +0900 net: dlink: add synchronization for stats update [ Upstream commit 12889ce926e9a9baf6b83d809ba316af539b89e2 ] This patch synchronizes code that accesses from both user-space and IRQ contexts. The `get_stats()` function can be called from both context. `dev->stats.tx_errors` and `dev->stats.collisions` are also updated in the `tx_errors()` function. Therefore, these fields must also be protected by synchronized. There is no code that accessses `dev->stats.tx_errors` between the previous and updated lines, so the updating point can be moved. Signed-off-by: Moon Yeounsu Link: https://patch.msgid.link/20250515075333.48290-1-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef1b88325c749021538e1c0ce0b66a9409521de7 Author: Tali Perry Date: Fri Mar 28 19:32:50 2025 +0000 i2c: npcm: Add clock toggle recovery [ Upstream commit 38010591a0fc3203f1cee45b01ab358b72dd9ab2 ] During init of the bus, the module checks that the bus is idle. If one of the lines are stuck try to recover them first before failing. Sometimes SDA and SCL are low if improper reset occurs (e.g., reboot). Signed-off-by: Tali Perry Signed-off-by: Mohammed Elbadry Reviewed-by: Mukesh Kumar Savaliya Link: https://lore.kernel.org/r/20250328193252.1570811-1-mohammed.0.elbadry@gmail.com Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit b08e4cebc0348c55d201c9dfb4bd6fc7a31a792b Author: Mike Tipton Date: Wed May 14 20:53:12 2025 -0700 cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs [ Upstream commit 6c9bb86922728c7a4cceb99f131e00dd87514f20 ] Currently, all SCMI devices with performance domains attempt to register a cpufreq driver, even if their performance domains aren't used to control the CPUs. The cpufreq framework only supports registering a single driver, so only the first device will succeed. And if that device isn't used for the CPUs, then cpufreq will scale the wrong domains. To avoid this, return early from scmi_cpufreq_probe() if the probing SCMI device isn't referenced by the CPU device phandles. This keeps the existing assumption that all CPUs are controlled by a single SCMI device. Signed-off-by: Mike Tipton Reviewed-by: Peng Fan Reviewed-by: Cristian Marussi Reviewed-by: Sudeep Holla Tested-by: Cristian Marussi Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit c0952a626fd94bf93af2edd7f8d3ad3b8da53022 Author: Petr Malat Date: Fri May 16 10:17:28 2025 +0200 sctp: Do not wake readers in __sctp_write_space() [ Upstream commit af295892a7abbf05a3c2ba7abc4d81bb448623d6 ] Function __sctp_write_space() doesn't set poll key, which leads to ep_poll_callback() waking up all waiters, not only these waiting for the socket being writable. Set the key properly using wake_up_interruptible_poll(), which is preferred over the sync variant, as writers are not woken up before at least half of the queue is available. Also, TCP does the same. Signed-off-by: Petr Malat Acked-by: Xin Long Link: https://patch.msgid.link/20250516081727.1361451-1-oss@malat.biz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70da1f7eb88a961c47783bc77da74aaddf1cac5d Author: Henk Vergonet Date: Fri Apr 18 16:39:14 2025 +0200 wifi: mt76: mt76x2: Add support for LiteOn WN4516R,WN4519R [ Upstream commit 3c0e4f606d8693795a2c965d6f4987b1bfc31097 ] Adds support for: - LiteOn WN4516R - LiteOn WN4519R Both use: - A nonstandard USB connector - Mediatek chipset MT7600U - ASIC revision: 76320044 Disabled VHT support on ASIC revision 76320044: This fixes the 5G connectibity issue on LiteOn WN4519R module see https://github.com/openwrt/mt76/issues/971 And may also fix the 5G issues on the XBox One Wireless Adapter see https://github.com/openwrt/mt76/issues/200 I have looked at the FCC info related to the MT7632U chip as mentioned in here: https://github.com/openwrt/mt76/issues/459 These confirm the chipset does not support 'ac' mode and hence VHT should be turned of. Signed-off-by: Henk Vergonet Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250418143914.31384-1-henk.vergonet@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit add1804ea2e08972f2556a3048eb9badf4ff09ad Author: Alok Tiwari Date: Mon May 19 07:17:19 2025 -0700 emulex/benet: correct command version selection in be_cmd_get_stats() [ Upstream commit edb888d29748cee674006a52e544925dacc7728e ] Logic here always sets hdr->version to 2 if it is not a BE3 or Lancer chip, even if it is BE2. Use 'else if' to prevent multiple assignments, setting version 0 for BE2, version 1 for BE3 and Lancer, and version 2 for others. Fixes potential incorrect version setting when BE2_chip and BE3_chip/lancer_chip checks could both be true. Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250519141731.691136-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b0e79c9cc2074c2546fe3c451f748d4152c5c22c Author: Tan En De Date: Sat Apr 12 10:33:03 2025 +0800 i2c: designware: Invoke runtime suspend on quick slave re-registration [ Upstream commit 2fe2b969d911a09abcd6a47401a3c66c38a310e6 ] Replaced pm_runtime_put() with pm_runtime_put_sync_suspend() to ensure the runtime suspend is invoked immediately when unregistering a slave. This prevents a race condition where suspend was skipped when unregistering and registering slave in quick succession. For example, consider the rapid sequence of `delete_device -> new_device -> delete_device -> new_device`. In this sequence, it is observed that the dw_i2c_plat_runtime_suspend() might not be invoked after `delete_device` operation. This is because after `delete_device` operation, when the pm_runtime_put() is about to trigger suspend, the following `new_device` operation might race and cancel the suspend. If that happens, during the `new_device` operation, dw_i2c_plat_runtime_resume() is skipped (since there was no suspend), which means `i_dev->init()`, i.e. i2c_dw_init_slave(), is skipped. Since i2c_dw_init_slave() is skipped, i2c_dw_configure_fifo_slave() is skipped too, which leaves `DW_IC_INTR_MASK` unconfigured. If we inspect the interrupt mask register using devmem, it will show as zero. Example shell script to reproduce the issue: ``` #!/bin/sh SLAVE_LADDR=0x1010 SLAVE_BUS=13 NEW_DEVICE=/sys/bus/i2c/devices/i2c-$SLAVE_BUS/new_device DELETE_DEVICE=/sys/bus/i2c/devices/i2c-$SLAVE_BUS/delete_device # Create initial device echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE sleep 2 # Rapid sequence of # delete_device -> new_device -> delete_device -> new_device echo $SLAVE_LADDR > $DELETE_DEVICE echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE echo $SLAVE_LADDR > $DELETE_DEVICE echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE # Using devmem to inspect IC_INTR_MASK will show as zero ``` Signed-off-by: Tan En De Acked-by: Jarkko Nikula Link: https://lore.kernel.org/r/20250412023303.378600-1-ende.tan@starfivetech.com Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit d99e45521ebbfea60e2c2980946d47560213a389 Author: Zilin Guan Date: Fri May 23 11:47:17 2025 +0000 tipc: use kfree_sensitive() for aead cleanup [ Upstream commit c8ef20fe7274c5766a317f9193b70bed717b6b3d ] The tipc_aead_free() function currently uses kfree() to release the aead structure. However, this structure contains sensitive information, such as key's SALT value, which should be securely erased from memory to prevent potential leakage. To enhance security, replace kfree() with kfree_sensitive() when freeing the aead structure. This change ensures that sensitive data is explicitly cleared before memory deallocation, aligning with the approach used in tipc_aead_init() and adhering to best practices for handling confidential information. Signed-off-by: Zilin Guan Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20250523114717.4021518-1-zilin@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 722e716966c29a7b85c985a76e2be839ab77c9dd Author: Sergio Perez Gonzalez Date: Sun May 25 21:20:31 2025 -0600 net: macb: Check return value of dma_set_mask_and_coherent() [ Upstream commit 3920a758800762917177a6b5ab39707d8e376fe6 ] Issue flagged by coverity. Add a safety check for the return value of dma_set_mask_and_coherent, go to a safe exit if it returns error. Link: https://scan7.scan.coverity.com/#/project-view/53936/11354?selectedIssue=1643754 Signed-off-by: Sergio Perez Gonzalez Reviewed-by: Claudiu Beznea Link: https://patch.msgid.link/20250526032034.84900-1-sperezglz@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1cf0a6f43399362e30f0068c3a6002395e7801f8 Author: Viresh Kumar Date: Thu Apr 24 21:50:18 2025 +0530 cpufreq: Force sync policy boost with global boost on sysfs update [ Upstream commit 121baab7b88ed865532dadb7ef1aee6e2bea86f5 ] If the global boost flag is enabled and policy boost flag is disabled, a call to `cpufreq_boost_trigger_state(true)` must enable the policy's boost state. The current code misses that because of an optimization. Fix it. Suggested-by: Lifeng Zheng Reviewed-by: Lifeng Zheng Signed-off-by: Viresh Kumar Link: https://patch.msgid.link/852ff11c589e6300730d207baac195b2d9d8b95f.1745511526.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ca41c10be5697cf4726515c4c31009973d152ed9 Author: George Moussalem Date: Fri Feb 28 09:11:36 2025 +0400 thermal/drivers/qcom/tsens: Update conditions to strictly evaluate for IP v2+ [ Upstream commit e3f90f167a49902cda2408f7e91cca0dcfd5040a ] TSENS v2.0+ leverage features not available to prior versions such as updated interrupts init routine, masked interrupts, and watchdog. Currently, the checks in place evaluate whether the IP version is greater than v1 which invalidates when updates to v1 or v1 minor versions are implemented. As such, update the conditional statements to strictly evaluate whether the version is greater than or equal to v2 (inclusive). Signed-off-by: George Moussalem Reviewed-by: Dmitry Baryshkov Reviewed-by: Amit Kucheria Link: https://lore.kernel.org/r/DS7PR19MB8883434CAA053648E22AA8AC9DCC2@DS7PR19MB8883.namprd19.prod.outlook.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 9a317e436265e2c652514a00b475749d2d613d0f Author: Sukrut Bellary Date: Tue Mar 18 16:00:40 2025 -0700 pmdomain: ti: Fix STANDBY handling of PER power domain [ Upstream commit 36795548dcc841c73f03793ed6cf741a88130922 ] Per AM335x TRM[1](section 8.1.4.3 Power mode), in case of STANDBY, PER domain should be ON. So, fix the PER power domain handling on standby. [1] https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf Signed-off-by: Sukrut Bellary Reviewed-by: Kevin Hilman Tested-by: Judith Mendez Link: https://lore.kernel.org/r/20250318230042.3138542-3-sbellary@baylibre.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 794b0efb20a863905de8516ac01b9451255bb9df Author: Simon Schuster Date: Thu Mar 27 14:54:22 2025 +0100 nios2: force update_mmu_cache on spurious tlb-permission--related pagefaults [ Upstream commit 2d8a3179ea035f9341b6a73e5ba4029fc67e983d ] NIOS2 uses a software-managed TLB for virtual address translation. To flush a cache line, the original mapping is replaced by one to physical address 0x0 with no permissions (rwx mapped to 0) set. This can lead to TLB-permission--related traps when such a nominally flushed entry is encountered as a mapping for an otherwise valid virtual address within a process (e.g. due to an MMU-PID-namespace rollover that previously flushed the complete TLB including entries of existing, running processes). The default ptep_set_access_flags implementation from mm/pgtable-generic.c only forces a TLB-update when the page-table entry has changed within the page table: /* * [...] We return whether the PTE actually changed, which in turn * instructs the caller to do things like update__mmu_cache. [...] */ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address, pte_t *ptep, pte_t entry, int dirty) { int changed = !pte_same(*ptep, entry); if (changed) { set_pte_at(vma->vm_mm, address, ptep, entry); flush_tlb_fix_spurious_fault(vma, address); } return changed; } However, no cross-referencing with the TLB-state occurs, so the flushing-induced pseudo entries that are responsible for the pagefault in the first place are never pre-empted from TLB on this code path. This commit fixes this behaviour by always requesting a TLB-update in this part of the pagefault handling, fixing spurious page-faults on the way. The handling is a straightforward port of the logic from the MIPS architecture via an arch-specific ptep_set_access_flags function ported from arch/mips/include/asm/pgtable.h. Signed-off-by: Simon Schuster Signed-off-by: Andreas Oetken Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit febbe1ce4c774d4b0872a4c6ab49a7aa8061ba34 Author: Shravan Chippa Date: Wed Mar 5 10:44:41 2025 +0530 media: i2c: imx334: update mode_3840x2160_regs array [ Upstream commit 35132d039c566b0e9d8e53f76f512b22607c2405 ] The 3840x2160 mode operates with the imx334 reset values. If we switch to other modes and then return to the 3840x2160 mode, it should function correctly. so updated the mode_3840x2160_regs array with the imx334 reset values. Signed-off-by: Shravan Chippa Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit bb97dfab7615fea97322b8a6131546e80f878a69 Author: Wentao Liang Date: Tue Apr 22 10:13:45 2025 +0800 media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode() [ Upstream commit bd9f6ce7d512fa21249415c16af801a4ed5d97b6 ] In fimc_is_hw_change_mode(), the function changes camera modes without waiting for hardware completion, risking corrupted data or system hangs if subsequent operations proceed before the hardware is ready. Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuring hardware state synchronization and stable interrupt handling. Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7a209e4b6b2a93ed609e19d280cefafc02f14f0a Author: Hans Verkuil Date: Tue Apr 1 11:54:17 2025 +0200 media: tc358743: ignore video while HPD is low [ Upstream commit 6829c5b5d26b1be31880d74ec24cb32d2d75f1ae ] If the HPD is low (happens if there is no EDID or the EDID is being updated), then return -ENOLINK in tc358743_get_detected_timings() instead of detecting video. This avoids userspace thinking that it can start streaming when the HPD is low. Signed-off-by: Hans Verkuil Tested-by: Maxime Ripard Link: https://lore.kernel.org/linux-media/20240628-stoic-bettong-of-fortitude-e25611@houat/ Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ba5026e805cb7a7c37ad38d9e1c34ddd0a96787f Author: Amber Lin Date: Tue Apr 22 15:54:19 2025 -0400 drm/amdkfd: Set SDMA_RLCx_IB_CNTL/SWITCH_INSIDE_IB [ Upstream commit ab9fcc6362e0699fc1150aa1d8503c40fce2c1e1 ] When submitting MQD to CP, set SDMA_RLCx_IB_CNTL/SWITCH_INSIDE_IB bit so it'll allow SDMA preemption if there is a massive command buffer of long-running SDMA commands. Signed-off-by: Amber Lin Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0a51b85b99609b26ccced8dd7446e2cb047c8299 Author: Dmitry Baryshkov Date: Fri Mar 7 08:24:53 2025 +0200 drm/msm/dpu: don't select single flush for active CTL blocks [ Upstream commit e93eee524bb78f3ee4b78654d0083382f98b3d23 ] In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF blocks. Don't skip programming the CTL on those targets. Tested-by: Neil Armstrong # on SM8550-QRD Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/641585/ Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-5-5d20655f10ca@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 4a8cb9908b51500a76f5156423bd295df53bff89 Author: Dylan Wolff Date: Wed Mar 12 16:02:00 2025 +0800 jfs: Fix null-ptr-deref in jfs_ioc_trim [ Upstream commit a4685408ff6c3e2af366ad9a7274f45ff3f394ee ] [ Syzkaller Report ] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] We believe that we have found a concurrency bug in the `fs/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings. To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program. Reported-and-tested-by: Dylan J. Wolff Reported-and-tested-by: Jiacheng Xu Signed-off-by: Dylan J. Wolff Signed-off-by: Jiacheng Xu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 258c755b28f6e5ef5d90beda5106fabf194e8484 Author: Alex Deucher Date: Wed Mar 19 11:57:49 2025 -0400 drm/amdgpu/gfx9: fix CSIB handling [ Upstream commit a4a4c0ae6742ec7d6bf1548d2c6828de440814a0 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7715a25c893058c12d2931c0a565768ba908ce9e Author: Alex Deucher Date: Wed Mar 19 11:57:34 2025 -0400 drm/amdgpu/gfx8: fix CSIB handling [ Upstream commit c8b8d7a4f1c5cdfbd61d75302fb3e3cdefb1a7ab ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 603c8dd458dacef0f074a9d4de632f60d9bc7bce Author: Zhang Yi Date: Wed Apr 23 16:52:53 2025 +0800 ext4: prevent stale extent cache entries caused by concurrent get es_cache [ Upstream commit f22a0ef2231a7d8374bb021eb86404d0e9de5a02 ] The EXT4_IOC_GET_ES_CACHE and EXT4_IOC_PRECACHE_EXTENTS currently invokes ext4_ext_precache() to preload the extent cache without holding the inode's i_rwsem. This can result in stale extent cache entries when competing with operations such as ext4_collapse_range() which calls ext4_ext_remove_space() or ext4_ext_shift_extents(). The problem arises when ext4_ext_remove_space() temporarily releases i_data_sem due to insufficient journal credits. During this interval, a concurrent EXT4_IOC_GET_ES_CACHE or EXT4_IOC_PRECACHE_EXTENTS may cache extent entries that are about to be deleted. As a result, these cached entries become stale and inconsistent with the actual extents. Loading the extents cache without holding the inode's i_rwsem or the mapping's invalidate_lock is not permitted besides during the writeback. Fix this by holding the i_rwsem during EXT4_IOC_GET_ES_CACHE and EXT4_IOC_PRECACHE_EXTENTS. Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20250423085257.122685-6-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 05aba2d316db1a59992c691f5ef8a1912a78f27b Author: Long Li Date: Sat Mar 1 14:48:36 2025 +0800 sunrpc: fix race in cache cleanup causing stale nextcheck time [ Upstream commit 2298abcbe11e9b553d03c0f1d084da786f7eff88 ] When cache cleanup runs concurrently with cache entry removal, a race condition can occur that leads to incorrect nextcheck times. This can delay cache cleanup for the cache_detail by up to 1800 seconds: 1. cache_clean() sets nextcheck to current time plus 1800 seconds 2. While scanning a non-empty bucket, concurrent cache entry removal can empty that bucket 3. cache_clean() finds no cache entries in the now-empty bucket to update the nextcheck time 4. This maybe delays the next scan of the cache_detail by up to 1800 seconds even when it should be scanned earlier based on remaining entries Fix this by moving the hash_lock acquisition earlier in cache_clean(). This ensures bucket emptiness checks and nextcheck updates happen atomically, preventing the race between cleanup and entry removal. Signed-off-by: Long Li Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 979408dbd76fdde5d3b3efbac2cb94aaa9b7fb9e Author: Nicolas Dufresne Date: Thu May 1 15:55:48 2025 -0400 media: rkvdec: Initialize the m2m context before the controls [ Upstream commit d43d7db3c8a1868dcbc6cb8de90a3cdf309d6cbb ] Setting up the control handler calls into .s_ctrl ops. While validating the controls the ops may need to access some of the context state, which could lead to a crash if not properly initialized. Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f29503cd7a1e45e05bfa0a6285b2604f062dc245 Author: Tomi Valkeinen Date: Wed Mar 26 13:34:02 2025 +0200 media: ti: cal: Fix wrong goto on error path [ Upstream commit a5b18fd769b7dc2e77a9e6a390844cbf50626ae8 ] If pm_runtime_resume_and_get() fails, we should unprepare the context, but currently we skip that as we goto to a later line. Reviewed-by: Kieran Bingham Signed-off-by: Tomi Valkeinen Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 44618bee303bed151ef3a525ff79fbd7689593b5 Author: Aditya Dutt Date: Tue Apr 1 20:59:16 2025 +0530 jfs: fix array-index-out-of-bounds read in add_missing_indices [ Upstream commit 5dff41a86377563f7a2b968aae00d25b4ceb37c9 ] stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error. Reported-by: syzbot+b974bd41515f770c608b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com./bug?extid=b974bd41515f770c608b Signed-off-by: Aditya Dutt Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit e3bb0c5a30719677758320371a9f075717c4c887 Author: Zhang Yi Date: Wed Apr 23 16:52:49 2025 +0800 ext4: ext4: unify EXT4_EX_NOCACHE|NOFAIL flags in ext4_ext_remove_space() [ Upstream commit 53ce42accd2002cc490fc86000ac532530507a74 ] When removing space, we should use EXT4_EX_NOCACHE because we don't need to cache extents, and we should also use EXT4_EX_NOFAIL to prevent metadata inconsistencies that may arise from memory allocation failures. While ext4_ext_remove_space() already uses these two flags in most places, they are missing in ext4_ext_search_right() and read_extent_tree_block() calls. Unify the flags to ensure consistent behavior throughout the extent removal process. Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20250423085257.122685-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 5179d4cf092e3ba689ec4eda5e64f177a7e43073 Author: Alex Deucher Date: Wed Mar 19 11:57:19 2025 -0400 drm/amdgpu/gfx7: fix CSIB handling [ Upstream commit be7652c23d833d1ab2c67b16e173b1a4e69d1ae6 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9cb5da9c83a82c0ef0bdbf10fab7da4309b15a4a Author: Nas Chung Date: Thu Jul 25 15:10:32 2024 +0900 media: uapi: v4l: Change V4L2_TYPE_IS_CAPTURE condition [ Upstream commit ad2698efce37e910dcf3c3914263e6cb3e86f8cd ] Explicitly compare a buffer type only with valid buffer types, to avoid matching a buffer type outside of the valid buffer type set. Signed-off-by: Nas Chung Reviewed-by: Michael Tretter Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit dc2aa8079d78fb40ec3901dd2d218c285d75a93f Author: Sakari Ailus Date: Wed Feb 26 14:27:58 2025 +0200 media: ccs-pll: Better validate VT PLL branch [ Upstream commit cd9cb0313a42ae029cd5af9293b0add984ed252e ] Check that the VT PLL dividers are actually found, don't trust they always are even though they should be. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b6fa8b7b8a6405c3bbb8669e84dc318e774fb4aa Author: Alex Deucher Date: Wed Mar 19 11:58:03 2025 -0400 drm/amdgpu/gfx10: fix CSIB handling [ Upstream commit 683308af030cd9b8d3f1de5cbc1ee51788878feb ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1db83a0b4f1f80d5255a5da991fb5ecd4481abcd Author: Tarang Raval Date: Sat Mar 29 11:13:28 2025 +0530 media: i2c: imx334: Fix runtime PM handling in remove function [ Upstream commit b493cd3c03641f9bbaa9787e43ca92163cb50051 ] pm_runtime_suspended() only checks the current runtime PM status and does not modify it, making it ineffective in this context. This could result in improper power management if the device remains active when removed. This patch fixes the issue by introducing a check with pm_runtime_status_suspended() to determine if the device is already suspended. If it is not, it calls imx334_power_off() to power down the device and then uses pm_runtime_set_suspended() to correctly update the runtime PM status to suspended. Signed-off-by: Tarang Raval Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 498e95513b5bc944e50cad14d69180f357a41a39 Author: Akhil P Oommen Date: Sat Apr 19 20:21:31 2025 +0530 drm/msm/a6xx: Increase HFI response timeout [ Upstream commit 5f02f5e78ec9688e29b6857813185b1181796abe ] When ACD feature is enabled, it triggers some internal calibrations which result in a pretty long delay during the first HFI perf vote. So, increase the HFI response timeout to match the downstream driver. Signed-off-by: Akhil P Oommen Tested-by: Maya Matuszczyk Tested-by: Anthony Ruhier Patchwork: https://patchwork.freedesktop.org/patch/649344/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6a4d3708dec420ba5707563d755b82033d177383 Author: Srinivasan Shanmugam Date: Fri Apr 18 00:57:19 2025 +0530 drm/amd/display: Add NULL pointer checks in dm_force_atomic_commit() [ Upstream commit 3f397cd203f247879c2f1a061e90d4c8d23655de ] This commit updates the dm_force_atomic_commit function to replace the usage of PTR_ERR_OR_ZERO with IS_ERR for checking error states after retrieving the Connector (drm_atomic_get_connector_state), CRTC (drm_atomic_get_crtc_state), and Plane (drm_atomic_get_plane_state) states. The function utilized PTR_ERR_OR_ZERO for error checking. However, this approach is inappropriate in this context because the respective functions do not return NULL; they return pointers that encode errors. This change ensures that error pointers are properly checked using IS_ERR before attempting to dereference. Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Tom Chung Cc: Roman Li Cc: Alex Hung Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bc487c490b7542de6fecb43fd5b979610892ac3e Author: Nas Chung Date: Thu Jul 25 15:10:34 2024 +0900 media: uapi: v4l: Fix V4L2_TYPE_IS_OUTPUT condition [ Upstream commit f81f69a0e3da141bdd73a16b8676f4e542533d87 ] V4L2_TYPE_IS_OUTPUT() returns true for V4L2_BUF_TYPE_VIDEO_OVERLAY which definitely belongs to CAPTURE. Signed-off-by: Nas Chung Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b905b9926ee149401e0dff7e91bf4abf1606e42b Author: Dmitry Baryshkov Date: Mon May 5 03:14:52 2025 +0300 drm/msm/hdmi: add runtime PM calls to DDC transfer function [ Upstream commit 531b4e2c206e5f7dead04d9da84dfa693ac57481 ] We must be sure that the HDMI controller is powered on, while performing the DDC transfer. Add corresponding runtime PM calls to msm_hdmi_i2c_xfer(). Reviewed-by: Jessica Zhang Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/651727/ Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-8-48541f76318c@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fce2d5e2b3ce1ef689ce891c912f0c19a1916728 Author: Tarang Raval Date: Sat Mar 29 11:13:29 2025 +0530 media: i2c: imx334: Enable runtime PM before sub-device registration [ Upstream commit 01dfdf6a80c57151af0589af0db7adbbdd1361c7 ] Runtime PM is fully initialized before calling v4l2_async_register_subdev_sensor(). Moving the runtime PM initialization earlier prevents potential access to an uninitialized or powered-down device. Signed-off-by: Tarang Raval Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit bcc8724b34c5125a0bbf863d218fc513b2cb0c25 Author: Ayushi Makhija Date: Mon May 5 15:12:45 2025 +0530 drm/bridge: anx7625: change the gpiod_set_value API [ Upstream commit 50935044e58e563cdcfd556d62f27bc8744dd64e ] Use gpiod_set_value_cansleep() instead of gpiod_set_value() to fix the below call trace in the boot log: [ 5.690534] Call trace: [ 5.690536] gpiod_set_value+0x40/0xa4 [ 5.690540] anx7625_runtime_pm_resume+0xa0/0x324 [anx7625] [ 5.690545] __rpm_callback+0x48/0x1d8 [ 5.690549] rpm_callback+0x6c/0x78 Certain GPIO controllers require access via message-based buses such as I2C or SPI, which may cause the GPIOs to enter a sleep state. Therefore, use the gpiod_set_value_cansleep(). Signed-off-by: Ayushi Makhija Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250505094245.2660750-7-quic_amakhija@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 66e84439ec2af776ce749e8540f8fdd257774152 Author: Namjae Jeon Date: Tue Apr 1 13:50:39 2025 +0900 exfat: fix double free in delayed_free [ Upstream commit 1f3d9724e16d62c7d42c67d6613b8512f2887c22 ] The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it. Reported-by: Jianzhou Zhao Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 3742e777735ab1ade3a66061c8f8c2decb9f6bb7 Author: Damon Ding Date: Mon Mar 10 18:41:02 2025 +0800 drm/bridge: analogix_dp: Add irq flag IRQF_NO_AUTOEN instead of calling disable_irq() [ Upstream commit efab13e7d13a641a22c7508cde6e1a5285161944 ] The IRQF_NO_AUTOEN can be used for the drivers that don't want interrupts to be enabled automatically via devm_request_threaded_irq(). Using this flag can provide be more robust compared to the way of calling disable_irq() after devm_request_threaded_irq() without the IRQF_NO_AUTOEN flag. Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Signed-off-by: Damon Ding Link: https://lore.kernel.org/r/20250310104114.2608063-2-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fbee3fe40ca289090eb22562831012bcecfd7494 Author: Long Li Date: Sat Mar 1 14:48:35 2025 +0800 sunrpc: update nextcheck time when adding new cache entries [ Upstream commit 5ca00634c8bbb2979c73465588f486b9632f5ed5 ] The cache_detail structure uses a "nextcheck" field to control hash table scanning intervals. When a table scan begins, nextcheck is set to current time plus 1800 seconds. During scanning, if cache_detail is not empty and a cache entry's expiry time is earlier than the current nextcheck, the nextcheck is updated to that expiry time. This mechanism ensures that: 1) Empty cache_details are scanned every 1800 seconds to avoid unnecessary scans 2) Non-empty cache_details are scanned based on the earliest expiry time found However, when adding a new cache entry to an empty cache_detail, the nextcheck time was not being updated, remaining at 1800 seconds. This could delay cache cleanup for up to 1800 seconds, potentially blocking threads(such as nfsd) that are waiting for cache cleanup. Fix this by updating the nextcheck time whenever a new cache entry is added. Signed-off-by: Long Li Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 767e4d5300ea50cd4569af05236627500d5f8035 Author: Alex Deucher Date: Wed Mar 19 11:56:02 2025 -0400 drm/amdgpu/gfx6: fix CSIB handling [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 767af6fc37875602a59d2e3c1c79e3be9234672f Author: Peter Marheine Date: Thu May 8 12:41:45 2025 +1000 ACPI: battery: negate current when discharging [ Upstream commit 234f71555019d308c6bc6f98c78c5551cb8cd56a ] The ACPI specification requires that battery rate is always positive, but the kernel ABI for POWER_SUPPLY_PROP_CURRENT_NOW (Documentation/ABI/testing/sysfs-class-power) specifies that it should be negative when a battery is discharging. When reporting CURRENT_NOW, massage the value to match the documented ABI. This only changes the sign of `current_now` and not `power_now` because documentation doesn't describe any particular meaning for `power_now` so leaving `power_now` unchanged is less likely to confuse userspace unnecessarily, whereas becoming consistent with the documented ABI is worth potentially confusing clients that read `current_now`. Signed-off-by: Peter Marheine Link: https://patch.msgid.link/20250508024146.1436129-1-pmarheine@chromium.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit abd7d5fb339416eddd831c7e0bb56beb73e5b8ed Author: Charan Teja Kalla Date: Thu May 15 12:11:25 2025 +0530 PM: runtime: fix denying of auto suspend in pm_suspend_timer_fn() [ Upstream commit 40d3b40dce375d6f1c1dbf08d79eed3aed6c691d ] pm_runtime_put_autosuspend() schedules a hrtimer to expire at "dev->power.timer_expires". If the hrtimer's callback, pm_suspend_timer_fn(), observes that the current time equals "dev->power.timer_expires", it unexpectedly bails out instead of proceeding with runtime suspend. pm_suspend_timer_fn(): if (expires > 0 && expires < ktime_get_mono_fast_ns()) { dev->power.timer_expires = 0; rpm_suspend(..) } Additionally, as ->timer_expires is not cleared, all the future auto suspend requests will not schedule hrtimer to perform auto suspend. rpm_suspend(): if ((rpmflags & RPM_AUTO) &&...) { if (!(dev->power.timer_expires && ...) { <-- this will fail. hrtimer_start_range_ns(&dev->power.suspend_timer,...); } } Fix this by as well checking if current time reaches the set expiration. Co-developed-by: Patrick Daly Signed-off-by: Patrick Daly Signed-off-by: Charan Teja Kalla Link: https://patch.msgid.link/20250515064125.1211561-1-quic_charante@quicinc.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 82608027b6e7b7f3cf004340fae6bbba85d7d01b Author: Yuanjun Gong Date: Tue May 13 20:37:44 2025 +0800 ASoC: tegra210_ahub: Add check to of_device_get_match_data() [ Upstream commit 04cb269c204398763a620d426cbee43064854000 ] In tegra_ahub_probe(), check the result of function of_device_get_match_data(), return an error code in case it fails. Signed-off-by: Yuanjun Gong Link: https://patch.msgid.link/20250513123744.3041724-1-ruc_gongyuanjun@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 64cc1a4a44409fc21ae293d9870f4dc0a32de296 Author: gldrk Date: Fri Apr 25 21:21:52 2025 +0200 ACPICA: utilities: Fix overflow check in vsnprintf() [ Upstream commit 12b660251007e00a3e4d47ec62dbe3a7ace7023e ] ACPICA commit d9d59b7918514ae55063b93f3ec041b1a569bf49 The old version breaks sprintf on 64-bit systems for buffers outside [0..UINT32_MAX]. Link: https://github.com/acpica/acpica/commit/d9d59b79 Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4994935.GXAFRqVoOG@rjwysocki.net Signed-off-by: gldrk [ rjw: Added the tag from gldrk ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6336d96ae88f398ae938ce312dd46538b72c30d9 Author: Jerry Lv Date: Tue Apr 15 11:40:47 2025 +0800 power: supply: bq27xxx: Retrieve again when busy [ Upstream commit f16d9fb6cf03fdbdefa41a8b32ba1e57afb7ae3d ] Multiple applications may access the battery gauge at the same time, so the gauge may be busy and EBUSY will be returned. The driver will set a flag to record the EBUSY state, and this flag will be kept until the next periodic update. When this flag is set, bq27xxx_battery_get_property() will just return ENODEV until the flag is updated. Even if the gauge was busy during the last accessing attempt, returning ENODEV is not ideal, and can cause confusion in the applications layer. Instead, retry accessing the I2C to update the flag is as expected, for the gauge typically recovers from busy state within a few milliseconds. If still failed to access the gauge, the real error code would be returned instead of ENODEV (as suggested by Pali Rohár). Reviewed-by: Pali Rohár Signed-off-by: Jerry Lv Link: https://lore.kernel.org/r/20250415-foo-fix-v2-1-5b45a395e4cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 960236150cd3f08e13b397dd5ae4ccf7a2986c00 Author: Seunghun Han Date: Wed Mar 26 21:06:21 2025 +0100 ACPICA: fix acpi parse and parseext cache leaks [ Upstream commit bed18f0bdcd6737a938264a59d67923688696fc4 ] ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x34f [ 0.392000] ? __class_create+0x4c/0x80 [ 0.392000] ? video_setup+0x7f/0x7f [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? do_one_initcall+0x4e/0x1a0 [ 0.392000] ? kernel_init_freeable+0x189/0x20a [ 0.392000] ? rest_init+0xc0/0xc0 [ 0.392000] ? kernel_init+0xa/0x100 [ 0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. "Acpi-Parse" cache and "Acpi-ParseExt" cache are used in an AML parse function, acpi_ps_parse_loop(). The function should complete all ops using acpi_ps_complete_final_op() when an error occurs due to invalid AML codes. However, the current implementation of acpi_ps_complete_final_op() does not complete all ops when it meets some errors and this cause cache leak. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. To fix ACPI cache leak for enhancing security, I made a patch to complete all ops unconditionally for acpi_ps_complete_final_op() function. I hope that this patch improves the security of Linux kernel. Thank you. Link: https://github.com/acpica/acpica/commit/8829e70e Signed-off-by: Seunghun Han Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2363774.ElGaqSPkdT@rjwysocki.net Signed-off-by: Sasha Levin commit 49047b184f2baf58197e2044a6fc95775fc4e1d4 Author: Armin Wolf Date: Sun May 18 20:51:11 2025 +0200 ACPI: bus: Bail out if acpi_kobj registration fails [ Upstream commit 94a370fc8def6038dbc02199db9584b0b3690f1a ] The ACPI sysfs code will fail to initialize if acpi_kobj is NULL, together with some ACPI drivers. Follow the other firmware subsystems and bail out if the kobject cannot be registered. Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20250518185111.3560-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 15fa571eedf1858327a381b4fbd014d94adadb75 Author: Hector Martin Date: Sun Apr 6 09:15:05 2025 +1000 ASoC: tas2770: Power cycle amp on ISENSE/VSENSE change [ Upstream commit f529c91be8a34ac12e7599bf87c65b6f4a2c9f5c ] The ISENSE/VSENSE blocks are only powered up when the amplifier transitions from shutdown to active. This means that if those controls are flipped on while the amplifier is already playing back audio, they will have no effect. Fix this by forcing a power cycle around transitions in those controls. Reviewed-by: Neal Gompa Signed-off-by: Hector Martin Signed-off-by: James Calligeros Link: https://patch.msgid.link/20250406-apple-codec-changes-v5-1-50a00ec850a3@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6448774d5889cb5f1d1591eed53afe04c9da23f0 Author: Ahmed Salem Date: Fri Apr 25 21:30:27 2025 +0200 ACPICA: Avoid sequence overread in call to strncmp() [ Upstream commit 64b9dfd0776e9c38d733094859a09f13282ce6f8 ] ACPICA commit 8b83a8d88dfec59ea147fad35fc6deea8859c58c ap_get_table_length() checks if tables are valid by calling ap_is_valid_header(). The latter then calls ACPI_VALIDATE_RSDP_SIG(Table->Signature). ap_is_valid_header() accepts struct acpi_table_header as an argument, so the signature size is always fixed to 4 bytes. The problem is when the string comparison is between ACPI-defined table signature and ACPI_SIG_RSDP. Common ACPI table header specifies the Signature field to be 4 bytes long[1], with the exception of the RSDP structure whose signature is 8 bytes long "RSD PTR " (including the trailing blank character)[2]. Calling strncmp(sig, rsdp_sig, 8) would then result in a sequence overread[3] as sig would be smaller (4 bytes) than the specified bound (8 bytes). As a workaround, pass the bound conditionally based on the size of the signature being passed. Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#system-description-table-header [1] Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#root-system-description-pointer-rsdp-structure [2] Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overread [3] Link: https://github.com/acpica/acpica/commit/8b83a8d8 Signed-off-by: Ahmed Salem Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2248233.Mh6RI2rZIc@rjwysocki.net Signed-off-by: Sasha Levin commit 106a648780bf1720c2db40262d24f62501d07092 Author: Guilherme G. Piccoli Date: Sun Mar 23 14:36:24 2025 -0300 clocksource: Fix the CPUs' choice in the watchdog per CPU verification [ Upstream commit 08d7becc1a6b8c936e25d827becabfe3bff72a36 ] Right now, if the clocksource watchdog detects a clocksource skew, it might perform a per CPU check, for example in the TSC case on x86. In other words: supposing TSC is detected as unstable by the clocksource watchdog running at CPU1, as part of marking TSC unstable the kernel will also run a check of TSC readings on some CPUs to be sure it is synced between them all. But that check happens only on some CPUs, not all of them; this choice is based on the parameter "verify_n_cpus" and in some random cpumask calculation. So, the watchdog runs such per CPU checks on up to "verify_n_cpus" random CPUs among all online CPUs, with the risk of repeating CPUs (that aren't double checked) in the cpumask random calculation. But if "verify_n_cpus" > num_online_cpus(), it should skip the random calculation and just go ahead and check the clocksource sync between all online CPUs, without the risk of skipping some CPUs due to duplicity in the random cpumask calculation. Tests in a 4 CPU laptop with TSC skew detected led to some cases of the per CPU verification skipping some CPU even with verify_n_cpus=8, due to the duplicity on random cpumask generation. Skipping the randomization when the number of online CPUs is smaller than verify_n_cpus, solves that. Suggested-by: Thadeu Lima de Souza Cascardo Signed-off-by: Guilherme G. Piccoli Signed-off-by: Thomas Gleixner Reviewed-by: Paul E. McKenney Link: https://lore.kernel.org/all/20250323173857.372390-1-gpiccoli@igalia.com Signed-off-by: Sasha Levin commit 5a68893b594ee6ce0efce5f74c07e64e9dd0c2c4 Author: Seunghun Han Date: Wed Mar 26 21:05:24 2025 +0100 ACPICA: fix acpi operand cache leak in dswstate.c [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin commit bf68c0f4c75f91eb59aacd22fa246a795e4d1e30 Author: David Lechner Date: Mon Apr 28 20:55:34 2025 -0500 iio: adc: ad7606_spi: fix reg write value mask commit 89944d88f8795c6c89b9514cb365998145511cd4 upstream. Fix incorrect value mask for register write. Register values are 8-bit, not 9. If this function was called with a value > 0xFF and an even addr, it would cause writing to the next register. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Signed-off-by: David Lechner Reviewed-by: Angelo Dureghello Link: https://patch.msgid.link/20250428-iio-adc-ad7606_spi-fix-write-value-mask-v1-1-a2d5e85a809f@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4b2fac04ed6fc007a86d43bdb0586ca363ec94c2 Author: Sean Nyekjaer Date: Fri May 2 11:37:26 2025 +0200 iio: imu: inv_icm42600: Fix temperature calculation commit e2f820014239df9360064079ae93f838ff3b7f8c upstream. >From the documentation: "offset to be added to [Y]_raw prior toscaling by [Y]_scale" Offset should be applied before multiplying scale, so divide offset by scale to make this correct. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Sean Nyekjaer Acked-by: Jean-Baptiste Maneyrol Link: https://patch.msgid.link/20250502-imu-v1-1-129b8391a4e3@geanix.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e401d55901a83cf022b81d28e892c69f356a6321 Author: Sean Nyekjaer Date: Mon May 5 21:20:08 2025 +0200 iio: accel: fxls8962af: Fix temperature scan element sign commit 9c78317b42e7c32523c91099859bc4721e9f75dd upstream. Mark the temperature element signed, data read from the TEMP_OUT register is in two's complement format. This will avoid the temperature being mishandled and miss displayed. Fixes: a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers") Suggested-by: Marcelo Schmitt Cc: stable@vger.kernel.org Reviewed-by: Marcelo Schmitt Signed-off-by: Sean Nyekjaer Link: https://patch.msgid.link/20250505-fxls-v4-2-a38652e21738@geanix.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fe551adf4bd399111fb31e01fce1b53bdfb26bca Author: Diederik de Haas Date: Thu Apr 17 16:21:18 2025 +0200 PCI: dw-rockchip: Fix PHY function call sequence in rockchip_pcie_phy_deinit() commit 286ed198b899739862456f451eda884558526a9d upstream. The documentation for the phy_power_off() function explicitly says that it must be called before phy_exit(). Hence, follow the same rule in rockchip_pcie_phy_deinit(). Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Diederik de Haas [mani: commit message change] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Dragan Simic Acked-by: Shawn Lin Cc: stable@vger.kernel.org # v5.15+ Link: https://patch.msgid.link/20250417142138.1377451-1-didi.debian@cknow.org Signed-off-by: Greg Kroah-Hartman commit ff1283be679cc159f9a7d3ffa92783377a3ebe56 Author: Ilpo Järvinen Date: Mon May 5 14:54:12 2025 +0300 PCI: Fix lock symmetry in pci_slot_unlock() commit f3efb9569b4a21354ef2caf7ab0608a3e14cc6e4 upstream. The commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") made the lock function to call depend on dev->subordinate but left pci_slot_unlock() unmodified creating locking asymmetry compared with pci_slot_lock(). Because of the asymmetric lock handling, the same bridge device is unlocked twice. First pci_bus_unlock() unlocks bus->self and then pci_slot_unlock() will unconditionally unlock the same bridge device. Move pci_dev_unlock() inside an else branch to match the logic in pci_slot_lock(). Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Dave Jiang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250505115412.37628-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a040e7effbb6279967cf4ad7487fedb89edab727 Author: Huacai Chen Date: Thu Apr 3 12:07:56 2025 +0800 PCI: Add ACS quirk for Loongson PCIe commit 1f3303aa92e15fa273779acac2d0023609de30f1 upstream. Loongson PCIe Root Ports don't advertise an ACS capability, but they do not allow peer-to-peer transactions between Root Ports. Add an ACS quirk so each Root Port can be in a separate IOMMU group. Signed-off-by: Xianglai Li Signed-off-by: Huacai Chen Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250403040756.720409-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman commit 2fd7537ffd9c6fc46c930b6ae7b187b611e0090f Author: Niklas Cassel Date: Wed May 14 09:43:15 2025 +0200 PCI: cadence-ep: Correct PBA offset in .set_msix() callback commit c8bcb01352a86bc5592403904109c22b66bd916e upstream. While cdns_pcie_ep_set_msix() writes the Table Size field correctly (N-1), the calculation of the PBA offset is wrong because it calculates space for (N-1) entries instead of N. This results in the following QEMU error when using PCI passthrough on a device which relies on the PCI endpoint subsystem: failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they don't fit in BARs, or don't align Fix the calculation of PBA offset in the MSI-X capability. [bhelgaas: more specific subject and commit log] Fixes: 3ef5d16f50f8 ("PCI: cadence: Add MSI-X support to Endpoint driver") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Wilfred Mallawa Reviewed-by: Damien Le Moal Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250514074313.283156-10-cassel@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8ec133fb054a9c587afbb620096de866bafb91f6 Author: Long Li Date: Mon May 5 17:56:34 2025 -0700 uio_hv_generic: Use correct size for interrupt and monitor pages commit c951ab8fd3589cf6991ed4111d2130816f2e3ac2 upstream. Interrupt and monitor pages should be in Hyper-V page size (4k bytes). This can be different from the system page size. This size is read and used by the user-mode program to determine the mapped data region. An example of such user-mode program is the VMBus driver in DPDK. Cc: stable@vger.kernel.org Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Signed-off-by: Long Li Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/1746492997-4599-3-git-send-email-longli@linuxonhyperv.com Signed-off-by: Wei Liu Message-ID: <1746492997-4599-3-git-send-email-longli@linuxonhyperv.com> Signed-off-by: Greg Kroah-Hartman commit 3562c09feeb8d8e9d102ce6840e8c7d57a7feb5c Author: Xiaolei Wang Date: Wed Apr 30 17:20:43 2025 +0800 remoteproc: core: Release rproc->clean_table after rproc_attach() fails commit bcd241230fdbc6005230f80a4f8646ff5a84f15b upstream. When rproc->state = RPROC_DETACHED is attached to remote processor through rproc_attach(), if rproc_handle_resources() returns failure, then the clean table should be released, otherwise the following memory leak will occur. unreferenced object 0xffff000086a99800 (size 1024): comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............ 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............ backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16): Fixes: 9dc9507f1880 ("remoteproc: Properly deal with the resource table when detaching") Signed-off-by: Xiaolei Wang Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250430092043.1819308-3-xiaolei.wang@windriver.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit c56d6ef2711ee51b54f160ad0f25a381561f0287 Author: Xiaolei Wang Date: Wed Apr 30 17:20:42 2025 +0800 remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() commit 7692c9fbedd9087dc9050903f58095915458d9b1 upstream. When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the "goto" statements in rproc_attach(). replace the "unprepare_device" goto statement with "clean_up_resources" and get rid of the "unprepare_device" label. unreferenced object 0xffff0000861c5d00 (size 128): comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20 Fixes: 10a3d4079eae ("remoteproc: imx_rproc: move memory parsing to rproc_ops") Suggested-by: Mathieu Poirier Signed-off-by: Xiaolei Wang Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250430092043.1819308-2-xiaolei.wang@windriver.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit fbf3da023bd2d3d3047b65511bb743568fa7ae43 Author: Wentao Liang Date: Mon May 26 10:56:27 2025 +0800 regulator: max14577: Add error check for max14577_read_reg() commit 65271f868cb1dca709ff69e45939bbef8d6d0b70 upstream. The function max14577_reg_get_current_limit() calls the function max14577_read_reg(), but does not check its return value. A proper implementation can be found in max14577_get_online(). Add a error check for the max14577_read_reg() and return error code if the function fails. Fixes: b0902bbeb768 ("regulator: max14577: Add regulator driver for Maxim 14577") Cc: stable@vger.kernel.org # v3.14 Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20250526025627.407-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5155f04287e52e3325e478a457616fc6c1b196cf Author: Khem Raj Date: Sat Mar 29 08:39:03 2025 -0700 mips: Add -std= flag specified in KBUILD_CFLAGS to vdso CFLAGS commit 0f4ae7c6ecb89bfda026d210dcf8216fb67d2333 upstream. GCC 15 changed the default C standard dialect from gnu17 to gnu23, which should not have impacted the kernel because it explicitly requests the gnu11 standard in the main Makefile. However, mips/vdso code uses its own CFLAGS without a '-std=' value, which break with this dialect change because of the kernel's own definitions of bool, false, and true conflicting with the C23 reserved keywords. include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant 11 | false = 0, | ^~~~~ include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef' 35 | typedef _Bool bool; | ^~~~ include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards Add -std as specified in KBUILD_CFLAGS to the decompressor and purgatory CFLAGS to eliminate these errors and make the C standard version of these areas match the rest of the kernel. Signed-off-by: Khem Raj Cc: stable@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 2ec9fda98d1a043f8e0369dc56deb45554462db6 Author: Gabriel Shahrouzi Date: Sat Apr 19 21:30:09 2025 -0400 staging: iio: ad5933: Correct settling cycles encoding per datasheet commit 60638e2a2d4bc03798f00d5ab65ce9b83cb8b03b upstream. The AD5933 datasheet (Table 13) lists the maximum cycles to be 0x7FC (2044). Clamp the user input to the maximum effective value of 0x7FC cycles. Fixes: f94aa354d676 ("iio: impedance-analyzer: New driver for AD5933/4 Impedance Converter, Network Analyzer") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250420013009.847851-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9da3e442714f7f4393ff01c265c4959c03e88c2f Author: Qasim Ijaz Date: Mon May 26 19:36:07 2025 +0100 net: ch9200: fix uninitialised access during mii_nway_restart commit 9ad0452c0277b816a435433cca601304cfac7c21 upstream. In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=3361c2d6f78a3e0892f9 Tested-by: syzbot Fixes: 4a476bd6d1d9 ("usbnet: New driver for QinHeng CH9200 devices") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Link: https://patch.msgid.link/20250526183607.66527-1-qasdev00@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6805582abb720681dd1c87ff677f155dcf4e86c9 Author: Ye Bin Date: Thu May 29 19:19:54 2025 +0800 ftrace: Fix UAF when lookup kallsym after ftrace disabled commit f914b52c379c12288b7623bb814d0508dbe7481d upstream. The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue may happen as follows: (1) Add kprobe tracepoint; (2) insmod test.ko; (3) Module triggers ftrace disabled; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... The problem is when a module triggers an issue with ftrace and sets ftrace_disable. The ftrace_disable is set when an anomaly is discovered and to prevent any more damage, ftrace stops all text modification. The issue that happened was that the ftrace_disable stops more than just the text modification. When a module is loaded, its init functions can also be traced. Because kallsyms deletes the init functions after a module has loaded, ftrace saves them when the module is loaded and function tracing is enabled. This allows the output of the function trace to show the init function names instead of just their raw memory addresses. When a module is removed, ftrace_release_mod() is called, and if ftrace_disable is set, it just returns without doing anything more. The problem here is that it leaves the mod_list still around and if kallsyms is called, it will call into this code and access the module memory that has already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Where the "mod" no longer exists and triggers a UAF bug. Link: https://lore.kernel.org/all/20250523135452.626d8dcd@gandalf.local.home/ Cc: stable@vger.kernel.org Fixes: aba4b5c22cba ("ftrace: Save module init functions kallsyms symbols for tracing") Link: https://lore.kernel.org/20250529111955.2349189-2-yebin@huaweicloud.com Signed-off-by: Ye Bin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 445e7055a68dadc2c915a125f6f9d963032c75df Author: Mikulas Patocka Date: Tue Jun 3 18:53:17 2025 +0200 dm-mirror: fix a tiny race condition commit 829451beaed6165eb11d7a9fb4e28eb17f489980 upstream. There's a tiny race condition in dm-mirror. The functions queue_bio and write_callback grab a spinlock, add a bio to the list, drop the spinlock and wake up the mirrord thread that processes bios in the list. It may be possible that the mirrord thread processes the bio just after spin_unlock_irqrestore is called, before wakeup_mirrord. This spurious wake-up is normally harmless, however if the device mapper device is unloaded just after the bio was processed, it may be possible that wakeup_mirrord(ms) uses invalid "ms" pointer. Fix this bug by moving wakeup_mirrord inside the spinlock. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ee3639385312a0623b2d71184eab04f5be0c7449 Author: Wentao Liang Date: Mon May 19 23:42:24 2025 +0800 mtd: nand: sunxi: Add randomizer configuration before randomizer enable commit 4a5a99bc79cdc4be63933653682b0261a67a0c9f upstream. In sunxi_nfc_hw_ecc_read_chunk(), the sunxi_nfc_randomizer_enable() is called without the config of randomizer. A proper implementation can be found in sunxi_nfc_hw_ecc_read_chunks_dma(). Add sunxi_nfc_randomizer_config() before the start of randomization. Fixes: 4be4e03efc7f ("mtd: nand: sunxi: add randomizer support") Cc: stable@vger.kernel.org # v4.6 Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 45413b24251313c941b8d56c9ae2cf5f6b2f54fb Author: Wentao Liang Date: Mon May 26 11:43:44 2025 +0800 mtd: rawnand: sunxi: Add randomizer configuration in sunxi_nfc_hw_ecc_write_chunk commit 44ed1f5ff73e9e115b6f5411744d5a22ea1c855b upstream. The function sunxi_nfc_hw_ecc_write_chunk() calls the sunxi_nfc_hw_ecc_write_chunk(), but does not call the configuration function sunxi_nfc_randomizer_config(). Consequently, the randomization might not conduct correctly, which will affect the lifespan of NAND flash. A proper implementation can be found in sunxi_nfc_hw_ecc_write_page_dma(). Add the sunxi_nfc_randomizer_config() to config randomizer. Fixes: 4be4e03efc7f ("mtd: nand: sunxi: add randomizer support") Cc: stable@vger.kernel.org # v4.6 Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 6fe586c14d8f44f15f20c0963976c7b26876f6a4 Author: Jinliang Zheng Date: Tue Apr 15 17:02:32 2025 +0800 mm: fix ratelimit_pages update error in dirty_ratio_handler() commit f83f362d40ccceb647f7d80eb92206733d76a36b upstream. In dirty_ratio_handler(), vm_dirty_bytes must be set to zero before calling writeback_set_ratelimit(), as global_dirty_limits() always prioritizes the value of vm_dirty_bytes. It's domain_dirty_limits() that's relevant here, not node_dirty_ok: dirty_ratio_handler writeback_set_ratelimit global_dirty_limits(&dirty_thresh) <- ratelimit_pages based on dirty_thresh domain_dirty_limits if (bytes) <- bytes = vm_dirty_bytes <--------+ thresh = f1(bytes) <- prioritizes vm_dirty_bytes | else | thresh = f2(ratio) | ratelimit_pages = f3(dirty_thresh) | vm_dirty_bytes = 0 <- it's late! ---------------------+ This causes ratelimit_pages to still use the value calculated based on vm_dirty_bytes, which is wrong now. The impact visible to userspace is difficult to capture directly because there is no procfs/sysfs interface exported to user space. However, it will have a real impact on the balance of dirty pages. For example: 1. On default, we have vm_dirty_ratio=40, vm_dirty_bytes=0 2. echo 8192 > dirty_bytes, then vm_dirty_bytes=8192, vm_dirty_ratio=0, and ratelimit_pages is calculated based on vm_dirty_bytes now. 3. echo 20 > dirty_ratio, then since vm_dirty_bytes is not reset to zero when writeback_set_ratelimit() -> global_dirty_limits() -> domain_dirty_limits() is called, reallimit_pages is still calculated based on vm_dirty_bytes instead of vm_dirty_ratio. This does not conform to the actual intent of the user. Link: https://lkml.kernel.org/r/20250415090232.7544-1-alexjlzheng@tencent.com Fixes: 9d823e8f6b1b ("writeback: per task dirty rate limit") Signed-off-by: Jinliang Zheng Reviewed-by: MengEn Sun Cc: Andrea Righi Cc: Fenggaung Wu Cc: Jinliang Zheng Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3b4a50d733acad6831f6bd9288a76a80f70650ac Author: Shin'ichiro Kawasaki Date: Sat May 10 19:10:36 2025 +0900 RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction commit 6883b680e703c6b2efddb4e7a8d891ce1803d06b upstream. The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cm_id destruction. However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver. To avoid the use-after-free of cm_id_private work objects, ensure that the last reference to the cm_id is decremented not in the event handler works, but in the cm_id destruction context. For that purpose, move iwcm_deref_id() call from destroy_cm_id() to the callers of destroy_cm_id(). In iw_destroy_cm_id(), call iwcm_deref_id() after flushing the pending works. During the fix work, I noticed that iw_destroy_cm_id() is called from cm_work_handler() and process_event() context. However, the comment of iw_destroy_cm_id() notes that the function "cannot be called by the event thread". Drop the false comment. Closes: https://lore.kernel.org/linux-rdma/r5676e754sv35aq7cdsqrlnvyhiq5zktteaurl7vmfih35efko@z6lay7uypy3c/ Fixes: 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") Cc: stable@vger.kernel.org Signed-off-by: Shin'ichiro Kawasaki Link: https://patch.msgid.link/20250510101036.1756439-1-shinichiro.kawasaki@wdc.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 74bc813d11c30e28fc5261dc877cca662ccfac68 Author: Jeongjun Park Date: Thu Apr 24 23:33:22 2025 +0900 ipc: fix to protect IPCS lookups using RCU commit d66adabe91803ef34a8b90613c81267b5ded1472 upstream. syzbot reported that it discovered a use-after-free vulnerability, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() is protected by rwsem, but this is not enough. If it is not protected by RCU read-critical region, when idr_for_each() calls radix_tree_node_free() through call_rcu() to free the radix_tree_node structure, the node will be freed immediately, and when reading the next node in radix_tree_for_each_slot(), the already freed memory may be read. Therefore, we need to add code to make sure that idr_for_each() is protected within the RCU read-critical region when we call it in shm_destroy_orphaned(). Link: https://lkml.kernel.org/r/20250424143322.18830-1-aha310510@gmail.com Fixes: b34a6b1da371 ("ipc: introduce shm_rmid_forced sysctl") Signed-off-by: Jeongjun Park Reported-by: syzbot+a2b84e569d06ca3a949c@syzkaller.appspotmail.com Cc: Jeongjun Park Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Vasiliy Kulikov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b0dba0c783232e0962da2255f71aa7eb98bc1552 Author: Da Xue Date: Mon May 12 10:26:16 2025 -0400 clk: meson-g12a: add missing fclk_div2 to spicc commit daf004f87c3520c414992893e2eadd5db5f86a5a upstream. SPICC is missing fclk_div2, which means fclk_div5 and fclk_div7 indexes are wrong on this clock. This causes the spicc module to output sclk at 2.5x the expected rate when clock index 3 is picked. Adding the missing fclk_div2 resolves this. [jbrunet: amended commit description] Fixes: a18c8e0b7697 ("clk: meson: g12a: add support for the SPICC SCLK Source clocks") Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Da Xue Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20250512142617.2175291-1-da@libre.computer Signed-off-by: Jerome Brunet Signed-off-by: Greg Kroah-Hartman commit 1fd94aa3fff0a468ec7badc292109f47b9ceb573 Author: Arnd Bergmann Date: Tue May 20 11:00:46 2025 +0200 parisc: fix building with gcc-15 commit 7cbb015e2d3d6f180256cde0c908eab21268e7b9 upstream. The decompressor is built with the default C dialect, which is now gnu23 on gcc-15, and this clashes with the kernel's bool type definition: In file included from include/uapi/linux/posix_types.h:5, from arch/parisc/boot/compressed/misc.c:7: include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant 11 | false = 0, Add the -std=gnu11 argument here, as we do for all other architectures. Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit bf9c07864765864b968e59c7b72db91130d621ca Author: GONG Ruiqi Date: Sun Apr 27 10:53:03 2025 +0800 vgacon: Add check for vc_origin address range in vgacon_scroll() commit 864f9963ec6b4b76d104d595ba28110b87158003 upstream. Our in-house Syzkaller reported the following BUG (twice), which we believed was the same issue with [1]: ================================================================== BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393 ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364 print_report+0xba/0x280 mm/kasan/report.c:475 kasan_report+0xa9/0xe0 mm/kasan/report.c:588 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline] vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690 vfs_write+0x219/0x960 fs/read_write.c:584 ksys_write+0x12e/0x260 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... Allocated by task 5614: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:201 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x62/0x140 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031 con_font_set drivers/tty/vt/vt.c:4628 [inline] con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 __fput_sync+0x4c/0x60 fs/file_table.c:465 __do_sys_close fs/open.c:1580 [inline] __se_sys_close+0x68/0xd0 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 task_work_run+0x154/0x240 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:45 [inline] do_exit+0x8e5/0x1320 kernel/exit.c:874 do_group_exit+0xcd/0x280 kernel/exit.c:1023 get_signal+0x1675/0x1850 kernel/signal.c:2905 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218 do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The buggy address belongs to the object at ffff88800f5be000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 2656 bytes to the right of allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500) ... Memory state around the buggy address: ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== By analyzing the vmcore, we found that vc->vc_origin was somehow placed one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and further writings to /dev/vcs caused out-of-bounds reads (and writes right after) in vcs_write_buf_noattr(). Our further experiments show that in most cases, vc->vc_origin equals to vga_vram_base when the console is in KD_TEXT mode, and it's around vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around vc->vc_screenbuf while the console is in KD_TEXT mode, and then by writing the special 'ESC M' control sequence to the tty certain times (depends on the value of `vc->state.y - vc->vc_top`), we can eventually move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on QEMU: ``` int main() { const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top` int tty_fd, vcs_fd; const char *tty_path = "/dev/tty0"; const char *vcs_path = "/dev/vcs"; const char escape_seq[] = "\x1bM"; // ESC + M const char trigger_seq[] = "Let's trigger an OOB write."; struct vt_sizes vt_size = { 70, 2 }; int blank = TIOCL_BLANKSCREEN; tty_fd = open(tty_path, O_RDWR); char vesa_mode[] = { TIOCL_SETVESABLANK, 1 }; ioctl(tty_fd, TIOCLINUX, vesa_mode); ioctl(tty_fd, TIOCLINUX, &blank); ioctl(tty_fd, VT_RESIZE, &vt_size); for (int i = 0; i < RI_NUM; ++i) write(tty_fd, escape_seq, sizeof(escape_seq) - 1); vcs_fd = open(vcs_path, O_RDWR); write(vcs_fd, trigger_seq, sizeof(trigger_seq)); close(vcs_fd); close(tty_fd); return 0; } ``` To solve this problem, add an address range validation check in vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf. Reported-by: syzbot+9c09fda97a1a65ea859b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Co-developed-by: Yi Yang Signed-off-by: Yi Yang Signed-off-by: GONG Ruiqi Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 1a10d91766eb6ddfd5414e4785611e33a4fe0f9b Author: Murad Masimov Date: Mon Apr 28 18:34:07 2025 +0300 fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var commit 05f6e183879d9785a3cdf2f08a498bc31b7a20aa upstream. If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 1ee9bab209493381d948a5fe2bf86a9d5d4c7e6f Author: Niravkumar L Rabara Date: Tue May 27 07:57:07 2025 -0700 EDAC/altera: Use correct write width with the INTTEST register commit e5ef4cd2a47f27c0c9d8ff6c0f63a18937c071a3 upstream. On the SoCFPGA platform, the INTTEST register supports only 16-bit writes. A 32-bit write triggers an SError to the CPU so do 16-bit accesses only. [ bp: AI-massage the commit message. ] Fixes: c7b4be8db8bc ("EDAC, altera: Add Arria10 OCRAM ECC support") Signed-off-by: Niravkumar L Rabara Signed-off-by: Matthew Gerlach Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@kernel.org Link: https://lore.kernel.org/20250527145707.25458-1-matthew.gerlach@altera.com Signed-off-by: Greg Kroah-Hartman commit ac6992f72bd8e22679c1e147ac214de6a7093c23 Author: Krzysztof Kozlowski Date: Wed Jun 18 09:36:50 2025 +0200 NFC: nci: uart: Set tty->disc_data only in success path commit fc27ab48904ceb7e4792f0c400f1ef175edf16fe upstream. Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of "tty->disc_data=NULL" in nci_uart_tty_open(). Cc: Linus Torvalds Fixes: 9961127d4bce ("NFC: nci: add generic uart support") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20250618073649.25049-2-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 38ef48a8afef8df646b6f6ae7abb872f18b533c1 Author: Chao Yu Date: Mon Apr 14 18:55:20 2025 +0800 f2fs: fix to do sanity check on sit_bitmap_size commit 5db0d252c64e91ba1929c70112352e85dc5751e7 upstream. w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe The reaseon is: sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on(). Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic. Cc: stable@vger.kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit fbfe8446cd3274b9e367f5708d94574230a44409 Author: Jaegeuk Kim Date: Sat Apr 12 21:09:46 2025 +0000 f2fs: prevent kernel warning due to negative i_nlink from corrupted image commit 42cb74a92adaf88061039601ddf7c874f58b554e upstream. WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Modules linked in: CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90 <0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6 ff RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005 RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000 R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0 FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0 Call Trace: f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline] f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845 f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909 f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581 vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544 do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608 __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline] __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline] __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652 do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb3d092324b Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0 RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0 R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0 R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001 Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit e5a2481dc2a0b430f49276d7482793a8923631d6 Author: Dan Carpenter Date: Fri May 30 16:13:32 2025 -0700 Input: ims-pcu - check record size in ims_pcu_flash_firmware() commit a95ef0199e80f3384eb992889322957d26c00102 upstream. The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);" Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/131fd1ae92c828ee9f4fa2de03d8c210ae1f3524.1748463049.git.dan.carpenter@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a597a609bfd4a2f6f4bce7b7d5f62769401c4c81 Author: Zhang Yi Date: Tue May 6 09:20:09 2025 +0800 ext4: ensure i_size is smaller than maxbytes commit 1a77a028a392fab66dd637cdfac3f888450d00af upstream. The inode i_size cannot be larger than maxbytes, check it while loading inode from the disk. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20250506012009.3896990-4-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9004a1cc5cfc69bd894cc82379fa3ec34ecff3c5 Author: Zhang Yi Date: Tue May 6 09:20:08 2025 +0800 ext4: factor out ext4_get_maxbytes() commit dbe27f06fa38b9bfc598f8864ae1c5d5831d9992 upstream. There are several locations that get the correct maxbytes value based on the inode's block type. It would be beneficial to extract a common helper function to make the code more clear. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20250506012009.3896990-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit c6187eb191a23e571faa0eee18a1471daa09274d Author: Jan Kara Date: Tue Apr 29 19:55:36 2025 +0200 ext4: fix calculation of credits for extent tree modification commit 32a93f5bc9b9812fc710f43a4d8a6830f91e4988 upstream. Luis and David are reporting that after running generic/750 test for 90+ hours on 2k ext4 filesystem, they are able to trigger a warning in jbd2_journal_dirty_metadata() complaining that there are not enough credits in the running transaction started in ext4_do_writepages(). Indeed the code in ext4_do_writepages() is racy and the extent tree can change between the time we compute credits necessary for extent tree computation and the time we actually modify the extent tree. Thus it may happen that the number of credits actually needed is higher. Modify ext4_ext_index_trans_blocks() to count with the worst case of maximum tree depth. This can reduce the possible number of writers that can operate in the system in parallel (because the credit estimates now won't fit in one transaction) but for reasonably sized journals this shouldn't really be an issue. So just go with a safe and simple fix. Link: https://lore.kernel.org/all/20250415013641.f2ppw6wov4kn4wq2@offworld Reported-by: Davidlohr Bueso Reported-by: Luis Chamberlain Tested-by: kdevops@lists.linux.dev Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250429175535.23125-2-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9d1d1c5bf4fc1af76be154d3afb2acdbd89ec7d8 Author: Thadeu Lima de Souza Cascardo Date: Tue Apr 15 11:53:04 2025 -0300 ext4: inline: fix len overflow in ext4_prepare_inline_data commit 227cb4ca5a6502164f850d22aec3104d7888b270 upstream. When running the following code on an ext4 filesystem with inline_data feature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL); That happens because write_begin will succeed as when ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len will be truncated, leading to ext4_prepare_inline_data parameter to be 6 instead of 0x10000000006. Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); at ext4_write_inline_data. Fix it by using a loff_t type for the len parameter in ext4_prepare_inline_data instead of an unsigned int. [ 44.545164] ------------[ cut here ]------------ [ 44.545530] kernel BUG at fs/ext4/inline.c:240! [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.546523] PKRU: 55555554 [ 44.546523] Call Trace: [ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0 [ 44.546523] generic_perform_write+0x17e/0x270 [ 44.546523] ext4_buffered_write_iter+0xc8/0x170 [ 44.546523] vfs_write+0x2be/0x3e0 [ 44.546523] __x64_sys_pwrite64+0x6d/0xc0 [ 44.546523] do_syscall_64+0x6a/0xf0 [ 44.546523] ? __wake_up+0x89/0xb0 [ 44.546523] ? xas_find+0x72/0x1c0 [ 44.546523] ? next_uptodate_folio+0x317/0x330 [ 44.546523] ? set_pte_range+0x1a6/0x270 [ 44.546523] ? filemap_map_pages+0x6ee/0x840 [ 44.546523] ? ext4_setattr+0x2fa/0x750 [ 44.546523] ? do_pte_missing+0x128/0xf70 [ 44.546523] ? security_inode_post_setattr+0x3e/0xd0 [ 44.546523] ? ___pte_offset_map+0x19/0x100 [ 44.546523] ? handle_mm_fault+0x721/0xa10 [ 44.546523] ? do_user_addr_fault+0x197/0x730 [ 44.546523] ? do_syscall_64+0x76/0xf0 [ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60 [ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90 [ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 44.546523] RIP: 0033:0x7f42999c6687 [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012 [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687 [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003 [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000 [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000000000000000 [ 44.546523] R13: 00007ffeae4a7ac8 R14: 00007f4299b86000 R15: 000055ea61493dd8 [ 44.546523] [ 44.546523] Modules linked in: [ 44.568501] ---[ end trace 0000000000000000 ]--- [ 44.568889] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.569328] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.570931] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.571356] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.571959] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.572571] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.573148] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.573748] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.574335] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.575027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.575520] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.576112] PKRU: 55555554 [ 44.576338] Kernel panic - not syncing: Fatal exception [ 44.576517] Kernel Offset: 0x1a600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Reported-by: syzbot+fe2a25dae02a207717a0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fe2a25dae02a207717a0 Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data") Signed-off-by: Thadeu Lima de Souza Cascardo Cc: stable@vger.kernel.org Reviewed-by: Jan Kara Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20250415-ext4-prepare-inline-overflow-v1-1-f4c13d900967@igalia.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 01cf92dfced52be7c043d86358c35eca424677f0 Author: Wan Junjie Date: Tue Apr 8 13:58:11 2025 +0300 bus: fsl-mc: fix GET/SET_TAILDROP command ids commit c78230ad34f82c6c0e0e986865073aeeef1f5d30 upstream. Command ids for taildrop get/set can not pass the check when they are using from the restool user space utility. Correct them according to the user manual. Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl") Signed-off-by: Wan Junjie Signed-off-by: Ioana Ciornei Cc: stable@vger.kernel.org Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250408105814.2837951-4-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit 0997566153bd1982fb727c25546b9868e8c4226d Author: Ioana Ciornei Date: Tue Apr 8 13:58:10 2025 +0300 bus: fsl-mc: do not add a device-link for the UAPI used DPMCP device commit dd7d8e012b23de158ca0188239c7a1f2a83b4484 upstream. The fsl-mc bus associated to the root DPRC in a DPAA2 system exports a device file for userspace access to the MC firmware. In case the DPRC's local MC portal (DPMCP) is currently in use, a new DPMCP device is allocated through the fsl_mc_portal_allocate() function. In this case, the call to fsl_mc_portal_allocate() will fail with -EINVAL when trying to add a device link between the root DPRC (consumer) and the newly allocated DPMCP device (supplier). This is because the DPMCP is a dependent of the DPRC device (the bus). Fix this by not adding a device link in case the DPMCP is allocated for the root DPRC's usage. Fixes: afb77422819f ("bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate") Signed-off-by: Ioana Ciornei Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250408105814.2837951-3-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit 7fc89c218fc96a296a2840b1e37f4e0975f7a108 Author: Tasos Sahanidis Date: Mon May 19 11:49:45 2025 +0300 ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 commit d29fc02caad7f94b62d56ee1b01c954f9c961ba7 upstream. The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues. Cc: stable@vger.kernel.org Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677 Signed-off-by: Tasos Sahanidis Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 312c121beb9c5edeca1c32a9f90e2e8b9be6e83a Author: Brett Werling Date: Thu Jun 12 14:18:25 2025 -0500 can: tcan4x5x: fix power regulator retrieval during probe commit db22720545207f734aaa9d9f71637bfc8b0155e0 upstream. Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring the regulator pointer is not set to NULL in the successful return from devm_regulator_get_optional(). Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config") Signed-off-by: Brett Werling Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 516fdd430171bc9a69c7525a9d3dc150256e5bf5 Author: Jeff Hugo Date: Fri Mar 28 10:35:26 2025 -0600 bus: mhi: host: Fix conflict between power_up and SYSERR commit 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 upstream. When mhi_async_power_up() enables IRQs, it is possible that we could receive a SYSERR notification from the device if the firmware has crashed for some reason. Then the SYSERR notification queues a work item that cannot execute until the pm_mutex is released by mhi_async_power_up(). So the SYSERR work item will be pending. If mhi_async_power_up() detects the SYSERR, it will handle it. If the device is in PBL, then the PBL state transition event will be queued, resulting in a work item after the pending SYSERR work item. Once mhi_async_power_up() releases the pm_mutex, the SYSERR work item can run. It will blindly attempt to reset the MHI state machine, which is the recovery action for SYSERR. PBL/SBL are not interrupt driven and will ignore the MHI Reset unless SYSERR is actively advertised. This will cause the SYSERR work item to timeout waiting for reset to be cleared, and will leave the host state in SYSERR processing. The PBL transition work item will then run, and immediately fail because SYSERR processing is not a valid state for PBL transition. This leaves the device uninitialized. This issue has a fairly unique signature in the kernel log: mhi mhi3: Requested to power ON Qualcomm Cloud AI 100 0000:36:00.0: Fatal error received from device. Attempting to recover mhi mhi3: Power on setup success mhi mhi3: Device failed to exit MHI Reset state mhi mhi3: Device MHI is not in valid state We cannot remove the SYSERR handling from mhi_async_power_up() because the device may be in the SYSERR state, but we missed the notification as the irq was fired before irqs were enabled. We also can't queue the SYSERR work item from mhi_async_power_up() if SYSERR is detected because that may result in a duplicate work item, and cause the same issue since the duplicate item will blindly issue MHI reset even if SYSERR is no longer active. Instead, add a check in the SYSERR work item to make sure that MHI reset is only issued if the device is in SYSERR state for PBL or SBL EEs. Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions") Signed-off-by: Jeffrey Hugo Signed-off-by: Jeff Hugo Signed-off-by: Manivannan Sadhasivam Reviewed-by: Troy Hanson Reviewed-by: Manivannan Sadhasivam cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250328163526.3365497-1-jeff.hugo@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 0e8878685902e97dfe4086493dbb2e90a667f770 Author: Andreas Kemnade Date: Mon Mar 31 16:44:39 2025 +0200 ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4 commit 7397daf1029d5bfd3415ec8622f5179603d5702d upstream. The late init call just writes to omap4 registers as soon as CONFIG_MFD_CPCAP is enabled without checking whether the cpcap driver is actually there or the SoC is indeed an OMAP4. Rather do these things only with the right device combination. Fixes booting the BT200 with said configuration enabled and non-factory X-Loader and probably also some surprising behavior on other devices. Fixes: c145649bf262 ("ARM: OMAP2+: Configure voltage controller for cpcap to low-speed") CC: stable@vger.kernel.org Signed-off-by: Andreas Kemnade Reivewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20250331144439.769697-1-andreas@kemnade.info Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 22441bf144ad2415581dd59b0291a93f626bb234 Author: Ross Stutterheim Date: Wed Apr 16 14:50:06 2025 +0100 ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap() commit 96e0b355883006554a0bee3697da475971d6bba8 upstream. arm/memremap: fix arch_memremap_can_ram_remap() commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") added the definition of arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages can be used from the linear mapping. memblock_is_map_memory() was called with the pfn of the address given to arch_memremap_can_ram_remap(); however, memblock_is_map_memory() expects to be given an address for arm, not a pfn. This results in calls to memremap() returning a newly mapped area when it should return an address in the existing linear mapping. Fix this by removing the address to pfn translation and pass the address directly. Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") Signed-off-by: Ross Stutterheim Cc: Mike Rapoport Cc: stable@vger.kernel.org Reviewed-by: Catalin Marinas Reviewed-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit b592691f650ced65b8f9c623df5e1c57eec07639 Author: Ricardo Ribalda Date: Thu Mar 13 12:20:39 2025 +0000 media: uvcvideo: Fix deferred probing error commit 387e8939307192d5a852a2afeeb83427fa477151 upstream. uvc_gpio_parse() can return -EPROBE_DEFER when the GPIOs it depends on have not yet been probed. This return code should be propagated to the caller of uvc_probe() to ensure that probing is retried when the required GPIOs become available. Currently, this error code is incorrectly converted to -ENODEV, causing some internal cameras to be ignored. This commit fixes this issue by propagating the -EPROBE_DEFER error. Cc: stable@vger.kernel.org Fixes: 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") Reviewed-by: Douglas Anderson Signed-off-by: Ricardo Ribalda Message-ID: <20250313-uvc-eprobedefer-v3-1-a1d312708eef@chromium.org> Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 739359516f96542b22ce9bd6c042d3f9c6a1da03 Author: Ricardo Ribalda Date: Mon Feb 24 10:34:54 2025 +0000 media: uvcvideo: Send control events for partial succeeds commit 5c791467aea6277430da5f089b9b6c2a9d8a4af7 upstream. Today, when we are applying a change to entities A, B. If A succeeds and B fails the events for A are not sent. This change changes the code so the events for A are send right after they happen. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-2-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e1019ff183fbd65323f9260189e810539f43bba8 Author: Ricardo Ribalda Date: Mon Feb 24 10:34:53 2025 +0000 media: uvcvideo: Return the number of processed controls commit ba4fafb02ad6a4eb2e00f861893b5db42ba54369 upstream. If we let know our callers that we have not done anything, they will be able to optimize their decisions. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-1-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 89b5ab822bf69867c3951dd0eb34b0314c38966b Author: Denis Arefev Date: Tue Apr 15 11:27:21 2025 +0300 media: vivid: Change the siize of the composing commit f83ac8d30c43fd902af7c84c480f216157b60ef0 upstream. syzkaller found a bug: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304 CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline] vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The composition size cannot be larger than the size of fmt_cap_rect. So execute v4l2_rect_map_inside() even if has_compose_cap == 0. Fixes: 94a7ad928346 ("media: vivid: fix compose size exceed boundary") Cc: stable@vger.kernel.org Reported-by: syzbot+365005005522b70a36f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=8ed8e8cc30cbe0d86c9a25bd1d6a5775129b8ea3 Signed-off-by: Denis Arefev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7e62be1f3b241bc9faee547864bb39332955509b Author: Edward Adam Davis Date: Tue Mar 11 15:20:14 2025 +0800 media: vidtv: Terminating the subsequent process of initialization failure commit 1d5f88f053480326873115092bc116b7d14916ba upstream. syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1] After PSI initialization fails, the si member is accessed again, resulting in this uaf. After si initialization fails, the subsequent process needs to be exited. [1] BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline] BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059 CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xd9/0x110 mm/kasan/report.c:634 vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f871d58d169 Code: Unable to access opcode bytes at 0x7f871d58d13f. RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169 RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003 R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840 Allocated by task 6059: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6059: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4609 [inline] kfree+0x2c4/0x4d0 mm/slub.c:4757 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:499 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 3be8037960bc ("media: vidtv: add error checks") Cc: stable@vger.kernel.org Reported-by: syzbot+0d33ab192bd50b6c91e6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0d33ab192bd50b6c91e6 Signed-off-by: Edward Adam Davis Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 230c37b5948d06eaf31c330001a20f1cf0ff11fb Author: Marek Szyprowski Date: Wed May 7 18:09:11 2025 +0200 media: videobuf2: use sgtable-based scatterlist wrappers commit a704a3c503ae1cfd9de8a2e2d16a0c9430e98162 upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgt->nents. Fixes: d4db5eb57cab ("media: videobuf2: add begin/end cpu_access callbacks to dma-sg") CC: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Reviewed-by: Sergey Senozhatsky Acked-by: Tomasz Figa Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 42f3fdd39fbde75e2ccfec99fd48f41df00289af Author: Loic Poulain Date: Thu Mar 27 13:53:04 2025 +0100 media: venus: Fix probe error handling commit 523cea3a19f0b3b020a4745344c136a636e6ffd7 upstream. Video device registering has been moved earlier in the probe function, but the new order has not been propagated to error handling. This means we can end with unreleased resources on error (e.g dangling video device on missing firmware probe aborting). Fixes: 08b1cf474b7f7 ("media: venus: core, venc, vdec: Fix probe dependency error") Cc: stable@vger.kernel.org Signed-off-by: Loic Poulain Reviewed-by: Dikshita Agarwal Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8b451a9a46f2bfc510e6d5c2492df91647586184 Author: Ma Ke Date: Wed Mar 19 16:02:48 2025 +0800 media: v4l2-dev: fix error handling in __video_register_device() commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a upstream. Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. And move callback function v4l2_device_release() and v4l2_device_get() before put_device(). As comment of device_register() says, 'NOTE: _Never_ directly free @dev after calling this function, even if it returned an error! Always use put_device() to give up the reference initialized in this function instead.' Found by code review. Cc: stable@vger.kernel.org Fixes: dc93a70cc7f9 ("V4L/DVB (9973): v4l2-dev: use the release callback from device instead of cdev") Signed-off-by: Ma Ke Reviewed-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a4c47df5953916aa8370dbc7da2b11c565dde556 Author: Wentao Liang Date: Tue Apr 22 11:07:39 2025 +0800 media: gspca: Add error handling for stv06xx_read_sensor() commit 398a1b33f1479af35ca915c5efc9b00d6204f8fa upstream. In hdcs_init(), the return value of stv06xx_read_sensor() needs to be checked. A proper implementation can be found in vv6410_dump(). Add a check in loop condition and propergate error code to fix this issue. Fixes: 4c98834addfe ("V4L/DVB (10048): gspca - stv06xx: New subdriver.") Cc: stable@vger.kernel.org # v2.6+ Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 41807a5f67420464ac8ee7741504f6b5decb3b7c Author: Edward Adam Davis Date: Sat Apr 5 19:56:41 2025 +0800 media: cxusb: no longer judge rbuf when the write fails commit 73fb3b92da84637e3817580fa205d48065924e15 upstream. syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=526bd95c0ec629993bf3 Tested-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com Fixes: 22c6d93a7310 ("[PATCH] dvb: usb: support Medion hybrid USB2.0 DVB-T/analogue box") Cc: stable@vger.kernel.org Signed-off-by: Edward Adam Davis Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6f79b25ddfe95aeaf1839c54253a920bfe703c1b Author: Sakari Ailus Date: Thu Feb 20 10:54:44 2025 +0200 media: ccs-pll: Check for too high VT PLL multiplier in dual PLL case commit 6868b955acd6e5d7405a2b730c2ffb692ad50d2c upstream. The check for VT PLL upper limit in dual PLL case was missing. Add it now. Fixes: 6c7469e46b60 ("media: ccs-pll: Add trivial dual PLL support") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0220fe256b44a8dc324b29de57c1b01da346d621 Author: Sakari Ailus Date: Wed Feb 19 15:06:11 2025 +0200 media: ccs-pll: Correct the upper limit of maximum op_pre_pll_clk_div commit f639494db450770fa30d6845d9c84b9cb009758f upstream. The PLL calculator does a search of the PLL configuration space for all valid OP pre-PLL clock dividers. The maximum did not take into account the CCS PLL flag CCS_PLL_FLAG_EXT_IP_PLL_DIVIDER in which case also odd PLL dividers (other than 1) are valid. Do that now. Fixes: 4e1e8d240dff ("media: ccs-pll: Add support for extended input PLL clock divider") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 64f7f8c362ab08c5e423c9be10c93b72c7bd5486 Author: Sakari Ailus Date: Tue Feb 18 23:43:58 2025 +0200 media: ccs-pll: Start OP pre-PLL multiplier search from correct value commit 660e613d05e449766784c549faf5927ffaf281f1 upstream. The ccs_pll_calculate() function does a search over possible PLL configurations to find the "best" one. If the sensor does not support odd pre-PLL divisors and the minimum value (with constraints) isn't 1, other odd values could be errorneously searched (and selected) for the pre-PLL divisor. Fix this. Fixes: 415ddd993978 ("media: ccs-pll: Split limits and PLL configuration into front and back parts") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fe52765d1c9078470581b90151f644453ae954a4 Author: Sakari Ailus Date: Tue Feb 18 23:47:13 2025 +0200 media: ccs-pll: Start VT pre-PLL multiplier search from correct value commit 06d2d478b09e6764fb6161d1621fc10d9f0f2860 upstream. The ccs_pll_calculate_vt_tree() function does a search over possible VT PLL configurations to find the "best" one. If the sensor does not support odd pre-PLL divisors and the minimum value (with constraints) isn't 1, other odd values could be errorneously searched (and selected) for the pre-PLL divisor. Fix this. Fixes: 415ddd993978 ("media: ccs-pll: Split limits and PLL configuration into front and back parts") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7fce1722991da76e706e8b9183942d40866dfab6 Author: Johan Hovold Date: Fri Apr 25 14:52:38 2025 +0200 media: ov8856: suppress probe deferral errors commit e3d86847fba58cf71f66e81b6a2515e07039ae17 upstream. Probe deferral should not be logged as an error: ov8856 24-0010: failed to get HW configuration: -517 Use dev_err_probe() for the clock lookup and drop the (mostly) redundant dev_err() from sensor probe() to suppress it. Note that errors during regulator lookup is already correctly logged using dev_err_probe(). Fixes: 0c2c7a1e0d69 ("media: ov8856: Add devicetree support") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 55fed78e52fe339c9874a5a1795c9ba6609093f1 Author: Mingcong Bai Date: Tue Apr 22 14:17:54 2025 +0800 wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723 commit 77a6407c6ab240527166fb19ee96e95f5be4d3cd upstream. RTL8723BE found on some ASUSTek laptops, such as F441U and X555UQ with subsystem ID 11ad:1723 are known to output large amounts of PCIe AER errors during and after boot up, causing heavy lags and at times lock-ups: pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5 pcieport 0000:00:1c.5: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) pcieport 0000:00:1c.5: device [8086:9d15] error status/mask=00000001/00002000 pcieport 0000:00:1c.5: [ 0] RxErr Disable ASPM on this combo as a quirk. This patch is a revision of a previous patch (linked below) which attempted to disable ASPM for RTL8723BE on all Intel Skylake and Kaby Lake PCIe bridges. I take a more conservative approach as all known reports point to ASUSTek laptops of these two generations with this particular wireless card. Please note, however, before the rtl8723be finishes probing, the AER errors remained. After the module finishes probing, all AER errors would indeed be eliminated, along with heavy lags, poor network throughput, and/or occasional lock-ups. Cc: Fixes: a619d1abe20c ("rtlwifi: rtl8723be: Add new driver") Reported-by: Liangliang Zou Link: https://bugzilla.kernel.org/show_bug.cgi?id=218127 Link: https://lore.kernel.org/lkml/05390e0b-27fd-4190-971e-e70a498c8221@lwfinger.net/T/ Tested-by: Liangliang Zou Signed-off-by: Mingcong Bai Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250422061755.356535-1-jeffbai@aosc.io Signed-off-by: Greg Kroah-Hartman commit 43d5e3bb5f1dcd91e30238ea0b59a5f77063f84e Author: Jeongjun Park Date: Wed May 14 22:08:55 2025 +0900 jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() commit af98b0157adf6504fade79b3e6cb260c4ff68e37 upstream. Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added. Reported-by: syzbot+de24c3fe3c4091051710@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de24c3fe3c4091051710 Fixes: 6e06ae88edae ("jbd2: speedup jbd2_journal_dirty_metadata()") Signed-off-by: Jeongjun Park Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250514130855.99010-1-aha310510@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0fccf5f01ed28725cc313a66ca1247eef911d55e Author: Li Lingfeng Date: Mon Apr 14 22:38:52 2025 +0800 nfsd: Initialize ssc before laundromat_work to prevent NULL dereference commit b31da62889e6d610114d81dc7a6edbcaa503fcf8 upstream. In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference. Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes. Fix this by moving nfsd_ssc initialization before starting laundromat_work. Fixes: f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Li Lingfeng Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 425efc6b3292a3c79bfee4a1661cf043dcd9cf2f Author: NeilBrown Date: Fri Mar 28 11:05:59 2025 +1100 nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request commit 1244f0b2c3cecd3f349a877006e67c9492b41807 upstream. If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure. Reported-by: Olga Kornievskaia Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1f7f8168abe8cbe845ab8bb557228d44784a6b57 Author: Christian Lamparter Date: Fri May 16 20:41:06 2025 +0200 wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() commit da1b9a55ff116cb040528ef664c70a4eec03ae99 upstream. Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default. Cc: Reported-by: Robert Morris Closes: https://lore.kernel.org/linux-wireless/28782.1747258414@localhost/ Fixes: 7cb770729ba8 ("p54: move eeprom code into common library") Signed-off-by: Christian Lamparter Link: https://patch.msgid.link/20250516184107.47794-1-chunkeey@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 8d5510e94dab740355c3557bf69e05673a9c3888 Author: Wentao Liang Date: Sun May 25 00:34:25 2025 +0800 net/mlx5: Add error handling in mlx5_query_nic_vport_node_guid() commit c6bb8a21cdad8c975a3a646b9e5c8df01ad29783 upstream. The function mlx5_query_nic_vport_node_guid() calls the function mlx5_query_nic_vport_context() but does not check its return value. A proper implementation can be found in mlx5_nic_vport_query_local_lb(). Add error handling for mlx5_query_nic_vport_context(). If it fails, free the out buffer via kvfree() and return error code. Fixes: 9efa75254593 ("net/mlx5_core: Introduce access functions to query vport RoCE fields") Cc: stable@vger.kernel.org # v4.5 Signed-off-by: Wentao Liang Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250524163425.1695-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea4b1cb6561e959075c88bb83bf7d26342ba0baa Author: Wentao Liang Date: Wed May 21 21:36:20 2025 +0800 net/mlx5_core: Add error handling inmlx5_query_nic_vport_qkey_viol_cntr() commit f0b50730bdd8f2734e548de541e845c0d40dceb6 upstream. The function mlx5_query_nic_vport_qkey_viol_cntr() calls the function mlx5_query_nic_vport_context() but does not check its return value. This could lead to undefined behavior if the query fails. A proper implementation can be found in mlx5_nic_vport_query_local_lb(). Add error handling for mlx5_query_nic_vport_context(). If it fails, free the out buffer via kvfree() and return error code. Fixes: 9efa75254593 ("net/mlx5_core: Introduce access functions to query vport RoCE fields") Cc: stable@vger.kernel.org # v4.5 Signed-off-by: Wentao Liang Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250521133620.912-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b0e86598e0737d62d46c2fc0e3146fda0510d36a Author: Gautam Menghani Date: Wed Mar 5 14:32:36 2025 +0530 powerpc/pseries/msi: Avoid reading PCI device registers in reduced power states commit 9cc0eafd28c7faef300822992bb08d79cab2a36c upstream. When a system is being suspended to RAM, the PCI devices are also suspended and the PPC code ends up calling pseries_msi_compose_msg() and this triggers the BUG_ON() in __pci_read_msi_msg() because the device at this point is in reduced power state. In reduced power state, the memory mapped registers of the PCI device are not accessible. To replicate the bug: 1. Make sure deep sleep is selected # cat /sys/power/mem_sleep s2idle [deep] 2. Make sure console is not suspended (so that dmesg logs are visible) echo N > /sys/module/printk/parameters/console_suspend 3. Suspend the system echo mem > /sys/power/state To fix this behaviour, read the cached msi message of the device when the device is not in PCI_D0 power state instead of touching the hardware. Fixes: a5f3d2c17b07 ("powerpc/pseries/pci: Add MSI domains") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Gautam Menghani Tested-by: Venkat Rao Bagalkote Reviewed-by: Vaibhav Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250305090237.294633-1-gautam@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 2023dea8dd9b93e8b6055fc8993b7a77cdb53a45 Author: Martin Blumenstingl Date: Sat Apr 19 23:34:48 2025 +0200 ASoC: meson: meson-card-utils: use of_property_present() for DT parsing commit 171eb6f71e9e3ba6a7410a1d93f3ac213f39dae2 upstream. Commit c141ecc3cecd ("of: Warn when of_property_read_bool() is used on non-boolean properties") added a warning when trying to parse a property with a value (boolean properties are defined as: absent = false, present without any value = true). This causes a warning from meson-card-utils. meson-card-utils needs to know about the existence of the "audio-routing" and/or "audio-widgets" properties in order to properly parse them. Switch to of_property_present() in order to silence the following warning messages during boot: OF: /sound: Read of boolean property 'audio-routing' with a value. OF: /sound: Read of boolean property 'audio-widgets' with a value. Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Tested-by: Christian Hewitt Cc: stable@vger.kernel.org Signed-off-by: Martin Blumenstingl Link: https://patch.msgid.link/20250419213448.59647-1-martin.blumenstingl@googlemail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 190dcc1e3f6ba14d1fdf722db358b65873bb3b0e Author: Wentao Liang Date: Mon May 19 15:57:39 2025 +0800 ASoC: qcom: sdm845: Add error handling in sdm845_slim_snd_hw_params() commit 688abe2860fd9c644705b9e11cb9649eb891b879 upstream. The function sdm845_slim_snd_hw_params() calls the functuion snd_soc_dai_set_channel_map() but does not check its return value. A proper implementation can be found in msm_snd_hw_params(). Add error handling for snd_soc_dai_set_channel_map(). If the function fails and it is not a unsupported error, return the error code immediately. Fixes: 5caf64c633a3 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga") Cc: stable@vger.kernel.org # v5.6 Signed-off-by: Wentao Liang Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20250519075739.1458-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5a16ebe0050e839a65ef16b7b6196dc82fdb62e4 Author: Alexander Aring Date: Mon Mar 31 19:03:24 2025 -0400 gfs2: move msleep to sleepable context commit ac5ee087d31ed93b6e45d2968a66828c6f621d8c upstream. This patch moves the msleep_interruptible() out of the non-sleepable context by moving the ls->ls_recover_spin spinlock around so msleep_interruptible() will be called in a sleepable context. Cc: stable@vger.kernel.org Fixes: 4a7727725dc7 ("GFS2: Fix recovery issues for spectators") Suggested-by: Andreas Gruenbacher Signed-off-by: Alexander Aring Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit e4da95e1246fcba9cfa55657e0c46965963dbc19 Author: Herbert Xu Date: Thu May 8 13:22:16 2025 +0800 crypto: marvell/cesa - Do not chain submitted requests commit 0413bcf0fc460a68a2a7a8354aee833293d7d693 upstream. This driver tries to chain requests together before submitting them to hardware in order to reduce completion interrupts. However, it even extends chains that have already been submitted to hardware. This is dangerous because there is no way of knowing whether the hardware has already read the DMA memory in question or not. Fix this by splitting the chain list into two. One for submitted requests and one for requests that have not yet been submitted. Only extend the latter. Reported-by: Klaus Kudielka Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining crypto requests in TDMA mode") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 8cb51a55b26eadc671748adbac12ebb2375ec9c1 Author: Zijun Hu Date: Wed May 7 19:50:26 2025 +0800 configfs: Do not override creating attribute file failure in populate_attrs() commit f830edbae247b89228c3e09294151b21e0dc849c upstream. populate_attrs() may override failure for creating attribute files by success for creating subsequent bin attribute files, and have wrong return value. Fix by creating bin attribute files under successfully creating attribute files. Fixes: 03607ace807b ("configfs: implement binary attributes") Cc: stable@vger.kernel.org Reviewed-by: Joel Becker Reviewed-by: Breno Leitao Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250507-fix_configfs-v3-2-fe2d96de8dc4@quicinc.com Signed-off-by: Andreas Hindborg Signed-off-by: Greg Kroah-Hartman commit 4ad892bdacb61323423bf09d22d7f5ccf4df3830 Author: Darrick J. Wong Date: Tue Jun 17 22:55:33 2025 +0200 xfs: allow inode inactivation during a ro mount log recovery [ Upstream commit 76e589013fec672c3587d6314f2d1f0aeddc26d9 ] In the next patch, we're going to prohibit log recovery if the primary superblock contains an unrecognized rocompat feature bit even on readonly mounts. This requires removing all the code in the log mounting process that temporarily disables the readonly state. Unfortunately, inode inactivation disables itself on readonly mounts. Clearing the iunlinked lists after log recovery needs inactivation to run to free the unreferenced inodes, which (AFAICT) is the only reason why log mounting plays games with the readonly state in the first place. Therefore, change the inactivation predicates to allow inactivation during log recovery of a readonly mount. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Stable-dep-of: 74ad4693b647 ("xfs: fix log recovery when unknown rocompat bits are set") Signed-off-by: Amir Goldstein Signed-off-by: Sasha Levin commit 7eac413a3ea3893916b67dbc4c7482d8c75ebe8f Author: Arnd Bergmann Date: Tue Feb 25 11:00:31 2025 +0100 kbuild: hdrcheck: fix cross build with clang commit 02e9a22ceef0227175e391902d8760425fa072c6 upstream. The headercheck tries to call clang with a mix of compiler arguments that don't include the target architecture. When building e.g. x86 headers on arm64, this produces a warning like clang: warning: unknown platform, assuming -mfloat-abi=soft Add in the KBUILD_CPPFLAGS, which contain the target, in order to make it build properly. See also 1b71c2fb04e7 ("kbuild: userprogs: fix bitsize and target detection on clang"). Reviewed-by: Nathan Chancellor Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 1b87636845291c025626466c644b88a00cba1d15 Author: Thomas Weißschuh Date: Thu Feb 13 15:55:17 2025 +0100 kbuild: userprogs: fix bitsize and target detection on clang commit 1b71c2fb04e7a713abc6edde4a412416ff3158f2 upstream. scripts/Makefile.clang was changed in the linked commit to move --target from KBUILD_CFLAGS to KBUILD_CPPFLAGS, as that generally has a broader scope. However that variable is not inspected by the userprogs logic, breaking cross compilation on clang. Use both variables to detect bitsize and target arguments for userprogs. Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 117ea3f4e59c42f77639b8ead6c0f269bbac846b Author: I Hsin Cheng Date: Tue May 6 02:43:38 2025 +0800 drm/meson: Use 1000ULL when operating with mode->clock commit eb0851e14432f3b87c77b704c835ac376deda03a upstream. Coverity scan reported the usage of "mode->clock * 1000" may lead to integer overflow. Use "1000ULL" instead of "1000" when utilizing it to avoid potential integer overflow issue. Link: https://scan5.scan.coverity.com/#/project-view/10074/10063?selectedIssue=1646759 Signed-off-by: I Hsin Cheng Reviewed-by: Martin Blumenstingl Fixes: 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") Link: https://lore.kernel.org/r/20250505184338.678540-1-richard120310@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Greg Kroah-Hartman commit 56e5419b5f5c5eed579b60527de6835c7d43b795 Author: Oliver Neukum Date: Wed May 28 13:03:54 2025 +0200 net: usb: aqc111: debug info before sanitation commit d3faab9b5a6a0477d69c38bd11c43aa5e936f929 upstream. If we sanitize error returns, the debug statements need to come before that so that we don't lose information. Signed-off-by: Oliver Neukum Fixes: 405b0d610745 ("net: usb: aqc111: fix error handling of usbnet read calls") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f77ba79a36de92b1171166f0887a584be42a43f Author: Eric Dumazet Date: Wed Jun 4 13:38:26 2025 +0000 calipso: unlock rcu before returning -EAFNOSUPPORT commit 3cae906e1a6184cdc9e4d260e4dbdf9a118d94ad upstream. syzbot reported that a recent patch forgot to unlock rcu in the error path. Adopt the convention that netlbl_conn_setattr() is already using. Fixes: 6e9f2df1c550 ("calipso: Don't call calipso functions for AF_INET sk.") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Kuniyuki Iwashima Acked-by: Paul Moore Link: https://patch.msgid.link/20250604133826.1667664-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2dace5e016c991424a3dc6e83b1ae5dca8992d08 Author: Thomas Gleixner Date: Wed Feb 26 16:01:57 2025 +0100 x86/iopl: Cure TIF_IO_BITMAP inconsistencies commit 8b68e978718f14fdcb080c2a7791c52a0d09bc6d upstream. io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state. Fixes: ea5f1cd7ab49 ("x86/ioperm: Remove bitmap if all permissions dropped") Reported-by: syzbot+e2b1803445d236442e54@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/87wmdceom2.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit 2a04a591170f1e8de1b1dc34fb8a5eb63abd88bc Author: Stefano Stabellini Date: Mon May 12 14:54:52 2025 -0700 xen/arm: call uaccess_ttbr0_enable for dm_op hypercall commit 7f9bbc1140ff8796230bc2634055763e271fd692 upstream. dm_op hypercalls might come from userspace and pass memory addresses as parameters. The memory addresses typically correspond to buffers allocated in userspace to hold extra hypercall parameters. On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be accessible by Xen, as a result ioreq hypercalls might fail. See the existing comment in arch/arm64/xen/hypercall.S regarding privcmd_call for reference. For privcmd_call, Linux calls uaccess_ttbr0_enable before issuing the hypercall thanks to commit 9cf09d68b89a. We need to do the same for dm_op. This resolves the problem. Cc: stable@kernel.org Fixes: 9cf09d68b89a ("arm64: xen: Enable user access before a privcmd hvc call") Signed-off-by: Stefano Stabellini Reviewed-by: Juergen Gross Message-ID: Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit e67c0dac405a04bc7c4adfd7af7f9a4712eef03f Author: Amit Sunil Dhamne Date: Fri May 2 16:57:03 2025 -0700 usb: typec: tcpm/tcpci_maxim: Fix bounds check in process_rx() commit 0736299d090f5c6a1032678705c4bc0a9511a3db upstream. Register read of TCPC_RX_BYTE_CNT returns the total size consisting of: PD message (pending read) size + 1 Byte for Frame Type (SOP*) This is validated against the max PD message (`struct pd_message`) size without accounting for the extra byte for the frame type. Note that the struct pd_message does not contain a field for the frame_type. This results in false negatives when the "PD message (pending read)" is equal to the max PD message size. Fixes: 6f413b559f86 ("usb: typec: tcpci_maxim: Chip level TCPC driver") Signed-off-by: Amit Sunil Dhamne Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Kyle Tso Cc: stable Link: https://lore.kernel.org/stable/20250502-b4-new-fix-pd-rx-count-v1-1-e5711ed09b3d%40google.com Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250502-b4-new-fix-pd-rx-count-v1-1-e5711ed09b3d@google.com Signed-off-by: Greg Kroah-Hartman commit 8bc30532b9784c6bd1a39361a30f664d745da3d1 Author: Mathias Nyman Date: Wed May 14 16:25:20 2025 +0300 usb: Flush altsetting 0 endpoints before reinitializating them after reset. commit 89bb3dc13ac29a563f4e4c555e422882f64742bd upstream. usb core avoids sending a Set-Interface altsetting 0 request after device reset, and instead relies on calling usb_disable_interface() and usb_enable_interface() to flush and reset host-side of those endpoints. xHCI hosts allocate and set up endpoint ring buffers and host_ep->hcpriv during usb_hcd_alloc_bandwidth() callback, which in this case is called before flushing the endpoint in usb_disable_interface(). Call usb_disable_interface() before usb_hcd_alloc_bandwidth() to ensure URBs are flushed before new ring buffers for the endpoints are allocated. Otherwise host driver will attempt to find and remove old stale URBs from a freshly allocated new ringbuffer. Cc: stable Fixes: 4fe0387afa89 ("USB: don't send Set-Interface after reset") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250514132520.225345-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f78b3fdd2c7f7d9a3d34f9146bb90b152f044f61 Author: Pawel Laszczak Date: Tue May 13 06:54:03 2025 +0000 usb: cdnsp: Fix issue with detecting USB 3.2 speed commit 2852788cfbe9ca1ab68509d65804413871f741f9 upstream. Patch adds support for detecting SuperSpeedPlus Gen1 x2 and SuperSpeedPlus Gen2 x2 speed. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB95387AD98EDCA695FECE52BADD96A@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 8c65ca53c2e64a828686ed092817e8b37f57ca3e Author: Pawel Laszczak Date: Tue May 13 05:30:09 2025 +0000 usb: cdnsp: Fix issue with detecting command completion event commit f4ecdc352646f7d23f348e5c544dbe3212c94fc8 upstream. In some cases, there is a small-time gap in which CMD_RING_BUSY can be cleared by controller but adding command completion event to event ring will be delayed. As the result driver will return error code. This behavior has been detected on usbtest driver (test 9) with configuration including ep1in/ep1out bulk and ep2in/ep2out isoc endpoint. Probably this gap occurred because controller was busy with adding some other events to event ring. The CMD_RING_BUSY is cleared to '0' when the Command Descriptor has been executed and not when command completion event has been added to event ring. To fix this issue for this test the small delay is sufficient less than 10us) but to make sure the problem doesn't happen again in the future the patch introduces 10 retries to check with delay about 20us before returning error code. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB9538AA45362ACCF1B94EE9B7DD96A@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b4209e4b778e4e57d0636e1c9fc07a924dbc6043 Author: Wupeng Ma Date: Sat May 10 11:30:40 2025 +0800 VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify commit 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4 upstream. During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast. Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs") Cc: stable Closes: https://lore.kernel.org/all/e91da589-ad57-3969-d979-879bbd10dddd@huawei.com/ Signed-off-by: Wupeng Ma Link: https://lore.kernel.org/r/20250510033040.901582-1-mawupeng1@huawei.com Signed-off-by: Greg Kroah-Hartman commit 6d929bef6bda8115e06e4cdc6b5fea36f290b871 Author: Dave Penkler Date: Wed May 21 14:16:55 2025 +0200 usb: usbtmc: Fix read_stb function and get_stb ioctl commit acb3dac2805d3342ded7dbbd164add32bbfdf21c upstream. The usbtmc488_ioctl_read_stb function relied on a positive return from usbtmc_get_stb to reset the srq condition in the driver. The USBTMC_IOCTL_GET_STB case tested for a positive return to return the stb to the user. Commit: ("usb: usbtmc: Fix erroneous get_stb ioctl error returns") changed the return value of usbtmc_get_stb to 0 on success instead of returning the value of usb_control_msg which is positive in the normal case. This change caused the function usbtmc488_ioctl_read_stb and the USBTMC_IOCTL_GET_STB ioctl to no longer function correctly. Change the test in usbtmc488_ioctl_read_stb to test for failure first and return the failure code immediately. Change the test for the USBTMC_IOCTL_GET_STB ioctl to test for 0 instead of a positive value. Fixes: cac01bd178d6 ("usb: usbtmc: Fix erroneous get_stb ioctl error returns") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250521121656.18174-3-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4751118c3ed85e417da5febd048db290df601ae7 Author: Nathan Chancellor Date: Wed Jun 4 14:08:09 2025 -0700 drm/amd/display: Do not add '-mhard-float' to dcn2{1,0}_resource.o for clang This patch is for linux-5.15.y and earlier only. It is functionally equivalent to upstream commit 7db038d9790e ("drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang"), which was created after all files that require '-mhard-float' were moved under the dml folder. In kernels older than 5.18, which do not contain upstream commits 22f87d998326 ("drm/amd/display: move FPU operations from dcn21 to dml/dcn20 folder") cf689e869cf0 ("drm/amd/display: move FPU-related code from dcn20 to dml folder") newer versions of clang error with clang: error: unsupported option '-mhard-float' for target 'x86_64-linux-gnu' make[6]: *** [scripts/Makefile.build:289: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.o] Error 1 clang: error: unsupported option '-mhard-float' for target 'x86_64-linux-gnu' make[6]: *** [scripts/Makefile.build:289: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o] Error 1 Apply a functionally equivalent change to prevent adding '-mhard-float' with clang for these files. Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 510ce6a1393c8b793e1b445f9da36eae22c78aa3 Author: Nathan Chancellor Date: Tue Jun 6 15:40:35 2023 -0700 kbuild: Add KBUILD_CPPFLAGS to as-option invocation commit 43fc0a99906e04792786edf8534d8d58d1e9de0c upstream. After commit feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS"), there is an error while building certain PowerPC assembly files with clang: arch/powerpc/lib/copypage_power7.S: Assembler messages: arch/powerpc/lib/copypage_power7.S:34: Error: junk at end of line: `0b01000' arch/powerpc/lib/copypage_power7.S:35: Error: junk at end of line: `0b01010' arch/powerpc/lib/copypage_power7.S:37: Error: junk at end of line: `0b01000' arch/powerpc/lib/copypage_power7.S:38: Error: junk at end of line: `0b01010' arch/powerpc/lib/copypage_power7.S:40: Error: junk at end of line: `0b01010' clang: error: assembler command failed with exit code 1 (use -v to see invocation) as-option only uses KBUILD_AFLAGS, so after removing CLANG_FLAGS from KBUILD_AFLAGS, there is no more '--target=' or '--prefix=' flags. As a result of those missing flags, the host target will be tested during as-option calls and likely fail, meaning necessary flags may not get added when building assembly files, resulting in errors like seen above. Add KBUILD_CPPFLAGS to as-option invocations to clear up the errors. This should have been done in commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target"), which switched from using the assembler target to the assembler-with-cpp target, so flags that affect preprocessing are passed along in all relevant tests. as-option now mirrors cc-option. Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/CA+G9fYs=koW9WardsTtora+nMgLR3raHz-LSLr58tgX4T5Mxag@mail.gmail.com/ Signed-off-by: Nathan Chancellor Tested-by: Naresh Kamboju Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 0690824cc3254c0f5899b15c9f9d47767217ffca Author: Masahiro Yamada Date: Sun Apr 9 23:53:57 2023 +0900 kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS commit feb843a469fb0ab00d2d23cfb9bcc379791011bb upstream. When preprocessing arch/*/kernel/vmlinux.lds.S, the target triple is not passed to $(CPP) because we add it only to KBUILD_{C,A}FLAGS. As a result, the linker script is preprocessed with predefined macros for the build host instead of the target. Assuming you use an x86 build machine, compare the following: $ clang -dM -E -x c /dev/null $ clang -dM -E -x c /dev/null -target aarch64-linux-gnu There is no actual problem presumably because our linker scripts do not rely on such predefined macros, but it is better to define correct ones. Move $(CLANG_FLAGS) to KBUILD_CPPFLAGS, so that all *.c, *.S, *.lds.S will be processed with the proper target triple. [Note] After the patch submission, we got an actual problem that needs this commit. (CBL issue 1859) Link: https://github.com/ClangBuiltLinux/linux/issues/1859 Reported-by: Tom Rini Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit f85d6a08cc9fbec8c98c34bc74074ae510007f29 Author: Nathan Chancellor Date: Thu Jun 1 12:50:39 2023 -0700 kbuild: Add CLANG_FLAGS to as-instr commit cff6e7f50bd315e5b39c4e46c704ac587ceb965f upstream. A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to KBUILD_CPPFLAGS so that '--target' is available while preprocessing. When that occurs, the following errors appear multiple times when building ARCH=powerpc powernv_defconfig: ld.lld: error: vmlinux.a(arch/powerpc/kernel/head_64.o):(.text+0x12d4): relocation R_PPC64_ADDR16_HI out of range: -4611686018409717520 is not in [-2147483648, 2147483647]; references '__start___soft_mask_table' ld.lld: error: vmlinux.a(arch/powerpc/kernel/head_64.o):(.text+0x12e8): relocation R_PPC64_ADDR16_HI out of range: -4611686018409717392 is not in [-2147483648, 2147483647]; references '__stop___soft_mask_table' Diffing the .o.cmd files reveals that -DHAVE_AS_ATHIGH=1 is not present anymore, because as-instr only uses KBUILD_AFLAGS, which will no longer contain '--target'. Mirror Kconfig's as-instr and add CLANG_FLAGS explicitly to the invocation to ensure the target information is always present. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit d36719f2937625afb37670dd32822afb492c6888 Author: Nathan Chancellor Date: Thu Jun 1 11:38:24 2023 -0700 mips: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation commit 08f6554ff90ef189e6b8f0303e57005bddfdd6a7 upstream. A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to KBUILD_CPPFLAGS so that '--target' is available while preprocessing. When that occurs, the following error appears when building ARCH=mips with clang (tip of tree error shown): clang: error: unsupported option '-mabi=' for target 'x86_64-pc-linux-gnu' Add KBUILD_CPPFLAGS in the CHECKFLAGS invocation to keep everything working after the move. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit d08146795689a0b2563b1eec8e4b6f4d050b2453 Author: Nathan Chancellor Date: Wed Jan 11 20:05:09 2023 -0700 drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang commit 7db038d9790eda558dd6c1dde4cdd58b64789c47 upstream. When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-mhard-float' [-Werror,-Wunused-command-line-argument] Similar to commit 84edc2eff827 ("selftest/fpu: avoid clang warning"), just add this flag to GCC builds. Commit 0f0727d971f6 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines") added '-msse2' to prevent clang from emitting software floating point routines. Signed-off-by: Nathan Chancellor Acked-by: Alex Deucher Tested-by: Linux Kernel Functional Testing Tested-by: Anders Roxell Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit cefb372db4981c90433a9302b4b32d2093480434 Author: Nick Desaulniers Date: Wed Jan 11 20:05:01 2023 -0700 kbuild: Update assembler calls to use proper flags and language target commit d5c8d6e0fa61401a729e9eb6a9c7077b2d3aebb0 upstream. as-instr uses KBUILD_AFLAGS, but as-option uses KBUILD_CFLAGS. This can cause as-option to fail unexpectedly when CONFIG_WERROR is set, because clang will emit -Werror,-Wunused-command-line-argument for various -m and -f flags in KBUILD_CFLAGS for assembler sources. Callers of as-option and as-instr should be adding flags to KBUILD_AFLAGS / aflags-y, not KBUILD_CFLAGS / cflags-y. Use KBUILD_AFLAGS in all macros to clear up the initial problem. Unfortunately, -Wunused-command-line-argument can still be triggered with clang by the presence of warning flags or macro definitions because '-x assembler' is used, instead of '-x assembler-with-cpp', which will consume these flags. Switch to '-x assembler-with-cpp' in places where '-x assembler' is used, as the compiler is always used as the driver for out of line assembler sources in the kernel. Finally, add -Werror to these macros so that they behave consistently whether or not CONFIG_WERROR is set. [nathan: Reworded and expanded on problems in commit message Use '-x assembler-with-cpp' in a couple more places] Link: https://github.com/ClangBuiltLinux/linux/issues/1699 Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Tested-by: Linux Kernel Functional Testing Tested-by: Anders Roxell Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 3b68784d1439f5e2859c07d719cde5457ce39685 Author: Nathan Chancellor Date: Wed Jan 11 20:05:00 2023 -0700 MIPS: Prefer cc-option for additions to cflags commit 337ff6bb8960fdc128cabd264aaea3d42ca27a32 upstream. A future change will switch as-option to use KBUILD_AFLAGS instead of KBUILD_CFLAGS to allow clang to drop -Qunused-arguments, which may cause issues if the flag being tested requires a flag previously added to KBUILD_CFLAGS but not KBUILD_AFLAGS. Use cc-option for cflags additions so that the flags are tested properly. Signed-off-by: Nathan Chancellor Acked-by: Thomas Bogendoerfer Reviewed-by: Nick Desaulniers Reviewed-by: Philippe Mathieu-Daudé Tested-by: Linux Kernel Functional Testing Tested-by: Anders Roxell Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 3ef47d2b7a41bbd950ede7b119629853e6df8618 Author: Nathan Chancellor Date: Wed Jun 14 11:04:36 2023 -0700 MIPS: Move '-Wa,-msoft-float' check from as-option to cc-option This patch is for linux-6.1.y and earlier, it has no direct mainline equivalent. In order to backport commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target") to resolve a separate issue regarding PowerPC, the problem noticed and fixed by commit 80a20d2f8288 ("MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT") needs to be addressed. Unfortunately, 6.1 and earlier do not contain commit e4412739472b ("Documentation: raise minimum supported version of binutils to 2.25"), so it cannot be assumed that all supported versions of GNU as have support for -msoft-float. In order to switch from KBUILD_CFLAGS to KBUILD_AFLAGS in as-option without consequence, move the '-Wa,-msoft-float' check to cc-option, including '$(cflags-y)' directly to avoid the issue mentioned in commit 80a20d2f8288 ("MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT"). Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit aaf384815bc1bf6d545a3073d71709575aacac99 Author: Nick Desaulniers Date: Wed Jan 11 20:04:58 2023 -0700 x86/boot/compressed: prefer cc-option for CFLAGS additions commit 994f5f7816ff963f49269cfc97f63cb2e4edb84f upstream. as-option tests new options using KBUILD_CFLAGS, which causes problems when using as-option to update KBUILD_AFLAGS because many compiler options are not valid assembler options. This will be fixed in a follow up patch. Before doing so, move the assembler test for -Wa,-mrelax-relocations=no from using as-option to cc-option. Link: https://lore.kernel.org/llvm/CAK7LNATcHt7GcXZ=jMszyH=+M_LC9Qr6yeAGRCBbE6xriLxtUQ@mail.gmail.com/ Suggested-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Tested-by: Linux Kernel Functional Testing Tested-by: Anders Roxell Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 2f3daa04a9328220de46f0d5c919a6c0073a9f0b Author: Oleg Nesterov Date: Fri Jun 13 19:26:50 2025 +0200 posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() commit f90fff1e152dedf52b932240ebbd670d83330eca upstream. If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case. Cc: stable@vger.kernel.org Reported-by: Benoît Sevens Fixes: 0bdd2ed4138e ("sched: run_posix_cpu_timers: Don't check ->exit_state, use lock_task_sighand()") Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c8c4f0c2684a035cab82344da02ba37d7ee71d8e Author: David Heimann Date: Sun Jun 1 12:41:16 2025 -0400 ALSA: usb-audio: Add implicit feedback quirk for RODE AI-1 commit 6a3439a417b910e662c666993798e0691bc81147 upstream. The RODE AI-1 audio interface requires implicit feedback sync between playback endpoint 0x03 and feedback endpoint 0x84 on interface 3, but doesn't advertise this in its USB descriptors. Without this quirk, the device receives audio data but produces no output. Signed-off-by: David Heimann Cc: Link: https://patch.msgid.link/084dc88c-1193-4a94-a002-5599adff936c@app.fastmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4a07125cc40dec630ae65a596f4911b3a6f3fccb Author: Peter Zijlstra Date: Fri Jan 17 10:54:50 2025 +0100 perf: Ensure bpf_perf_link path is properly serialized [ Upstream commit 7ed9138a72829d2035ecbd8dbd35b1bc3c137c40 ] Ravi reported that the bpf_perf_link_attach() usage of perf_event_set_bpf_prog() is not serialized by ctx->mutex, unlike the PERF_EVENT_IOC_SET_BPF case. Reported-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ravi Bangoria Link: https://lkml.kernel.org/r/20250307193305.486326750@infradead.org Signed-off-by: Sasha Levin commit 929d62e86f0c50084c8cee5537e3f7a5f8c4e0dc Author: Daniel Wagner Date: Wed May 7 14:23:03 2025 +0200 nvmet-fcloop: access fcpreq only when holding reqlock [ Upstream commit 47a827cd7929d0550c3496d70b417fcb5649b27b ] The abort handling logic expects that the state and the fcpreq are only accessed when holding the reqlock lock. While at it, only handle the aborts in the abort handler. Signed-off-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 64007aab1cf689333149c03aace6863c0ede9d24 Author: Zijun Hu Date: Thu Apr 10 19:45:27 2025 +0800 fs/filesystems: Fix potential unsigned integer underflow in fs_name() [ Upstream commit 1363c134ade81e425873b410566e957fecebb261 ] fs_name() has @index as unsigned int, so there is underflow risk for operation '@index--'. Fix by breaking the for loop when '@index == 0' which is also more proper than '@index <= 0' for unsigned integer comparison. Signed-off-by: Zijun Hu Link: https://lore.kernel.org/20250410-fix_fs-v1-1-7c14ccc8ebaa@quicinc.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 0b479d0aa488cb478eb2e1d8868be946ac8afb4f Author: Eric Dumazet Date: Wed Jun 11 11:15:14 2025 +0000 net_sched: ets: fix a race in ets_qdisc_change() [ Upstream commit d92adacdd8c2960be856e0b82acc5b7c5395fddb ] Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: b05972f01e7d ("net: sched: tbf: don't call qdisc_put() while holding tree lock") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250611111515.1983366-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 52247723c30077277d8760cf9f1c0cef4e5ee743 Author: Cong Wang Date: Thu Apr 3 14:10:27 2025 -0700 sch_ets: make est_qlen_notify() idempotent [ Upstream commit a7a15f39c682ac4268624da2abdb9114bdde96d5 ] est_qlen_notify() deletes its class from its active list with list_del() when qlen is 0, therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life. Also change other list_del()'s to list_del_init() just to be extra safe. Reported-by: Gerrard Tai Signed-off-by: Cong Wang Link: https://patch.msgid.link/20250403211033.166059-6-xiyou.wangcong@gmail.com Acked-by: Jamal Hadi Salim Signed-off-by: Paolo Abeni Stable-dep-of: d92adacdd8c2 ("net_sched: ets: fix a race in ets_qdisc_change()") Signed-off-by: Sasha Levin commit 852d27f773a7f470a5c767425240bc722baf5551 Author: Eric Dumazet Date: Wed Jun 11 11:15:13 2025 +0000 net_sched: tbf: fix a race in tbf_change() [ Upstream commit 43eb466041216d25dedaef1c383ad7bd89929cbc ] Gerrard Tai reported a race condition in TBF, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: b05972f01e7d ("net: sched: tbf: don't call qdisc_put() while holding tree lock") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Cc: Zhengchao Shao Link: https://patch.msgid.link/20250611111515.1983366-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 110a47efcf23438ff8d31dbd9c854fae2a48bf98 Author: Eric Dumazet Date: Wed Jun 11 11:15:12 2025 +0000 net_sched: red: fix a race in __red_change() [ Upstream commit 85a3e0ede38450ea3053b8c45d28cf55208409b8 ] Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 0c8d13ac9607 ("net: sched: red: delay destroying child qdisc on replace") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250611111515.1983366-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20f68e6a9e41693cb0e55e5b9ebbcb40983a4b8f Author: Eric Dumazet Date: Wed Jun 11 11:15:11 2025 +0000 net_sched: prio: fix a race in prio_tune() [ Upstream commit d35acc1be3480505b5931f17e4ea9b7617fea4d3 ] Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 7b8e0b6e6599 ("net: sched: prio: delay destroying child qdiscs on change") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250611111515.1983366-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc84c55f121db405b902ebb29a7d474bbaf21327 Author: Patrisious Haddad Date: Tue Jun 10 18:15:08 2025 +0300 net/mlx5: Fix return value when searching for existing flow group [ Upstream commit 8ec40e3f1f72bf8f8accf18020d487caa99f46a4 ] When attempting to add a rule to an existing flow group, if a matching flow group exists but is not active, the error code returned should be EAGAIN, so that the rule can be added to the matching flow group once it is active, rather than ENOENT, which indicates that no matching flow group was found. Fixes: bd71b08ec2ee ("net/mlx5: Support multiple updates of steering rules in parallel") Signed-off-by: Gavi Teitz Signed-off-by: Roi Dayan Signed-off-by: Patrisious Haddad Reviewed-by: Tariq Toukan Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-4-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ec31c2003f9054f97a8e8f65f10983588505601 Author: Moshe Shemesh Date: Tue Jun 10 18:15:06 2025 +0300 net/mlx5: Ensure fw pages are always allocated on same NUMA [ Upstream commit f37258133c1e95e61db532e14067e28b4881bf24 ] When firmware asks the driver to allocate more pages, using event of give_pages, the driver should always allocate it from same NUMA, the original device NUMA. Current code uses dev_to_node() which can result in different NUMA as it is changed by other driver flows, such as mlx5_dma_zalloc_coherent_node(). Instead, use saved numa node for allocating firmware pages. Fixes: 311c7c71c9bb ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-2-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 014ad9210373d2104f6ef10e6bb999a7a0a4c50e Author: Jakub Raczynski Date: Mon Jun 9 17:31:46 2025 +0200 net/mdiobus: Fix potential out-of-bounds read/write access [ Upstream commit 0e629694126ca388916f059453a1c36adde219c4 ] When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation. Fixes: 080bb352fad00 ("net: phy: Maintain MDIO device and bus statistics") Signed-off-by: Jakub Raczynski Reported-by: Wenjing Shan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 694456462ed63a06adbb0b7f2396a2eb5cc153c0 Author: Andrew Lunn Date: Mon Jan 9 16:30:44 2023 +0100 net: mdio: C22 is now optional, EOPNOTSUPP if not provided [ Upstream commit b063b1924fd9bf0bc157cf644764dc2151d04ccc ] When performing a C22 operation, check that the bus driver actually provides the methods, and return -EOPNOTSUPP if not. C45 only busses do exist, and in future their C22 methods will be NULL. Signed-off-by: Andrew Lunn Signed-off-by: Michael Walle Signed-off-by: Jakub Kicinski Stable-dep-of: 0e629694126c ("net/mdiobus: Fix potential out-of-bounds read/write access") Signed-off-by: Sasha Levin commit 268625b73e4cf2eb542848478d43a84198bd1b83 Author: Carlos Fernandez Date: Mon Jun 9 09:26:26 2025 +0200 macsec: MACsec SCI assignment for ES = 0 [ Upstream commit d9816ec74e6d6aa29219d010bba3f780ba1d9d75 ] According to 802.1AE standard, when ES and SC flags in TCI are zero, used SCI should be the current active SC_RX. Current code uses the header MAC address. Without this patch, when ES flag is 0 (using a bridge or switch), header MAC will not fit the SCI and MACSec frames will be discarted. In order to test this issue, MACsec link should be stablished between two interfaces, setting SC and ES flags to zero and a port identifier different than one. For example, using ip macsec tools: ip link add link $ETH0 macsec0 type macsec port 11 send_sci off end_station off ip macsec add macsec0 tx sa 0 pn 2 on key 01 $ETH1_KEY ip macsec add macsec0 rx port 11 address $ETH1_MAC ip macsec add macsec0 rx port 11 address $ETH1_MAC sa 0 pn 2 on key 02 ip link set dev macsec0 up ip link add link $ETH1 macsec1 type macsec port 11 send_sci off end_station off ip macsec add macsec1 tx sa 0 pn 2 on key 01 $ETH0_KEY ip macsec add macsec1 rx port 11 address $ETH0_MAC ip macsec add macsec1 rx port 11 address $ETH0_MAC sa 0 pn 2 on key 02 ip link set dev macsec1 up Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Co-developed-by: Andreu Montiel Signed-off-by: Andreu Montiel Signed-off-by: Carlos Fernandez Reviewed-by: Subbaraya Sundeep Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6fa68d7eab34d448a61aa24ea31e68b3231ed20d Author: Michal Luczaj Date: Mon Jun 9 19:08:03 2025 +0200 net: Fix TOCTOU issue in sk_is_readable() [ Upstream commit 2660a544fdc0940bba15f70508a46cf9a6491230 ] sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check. Fixes: 8934ce2fd081 ("bpf: sockmap redirect ingress support") Suggested-by: Jakub Sitnicki Signed-off-by: Michal Luczaj Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250609-skisreadable-toctou-v1-1-d0dfb2d62c37@rbox.co Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15e46043bc4683bc8c3fba195f624a343fb27e81 Author: Robert Malz Date: Tue May 20 10:31:52 2025 +0200 i40e: retry VFLR handling if there is ongoing VF reset [ Upstream commit fb4e9239e029954a37a00818b21e837cebf2aa10 ] When a VFLR interrupt is received during a VF reset initiated from a different source, the VFLR may be not fully handled. This can leave the VF in an undefined state. To address this, set the I40E_VFLR_EVENT_PENDING bit again during VFLR handling if the reset is not yet complete. This ensures the driver will properly complete the VF reset in such scenarios. Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF") Signed-off-by: Robert Malz Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5008c550c63413986c52a2df7093ae1e5b4031d9 Author: Robert Malz Date: Tue May 20 10:31:51 2025 +0200 i40e: return false from i40e_reset_vf if reset is in progress [ Upstream commit a2c90d63b71223d69a813333c1abf4fdacddbbe5 ] The function i40e_vc_reset_vf attempts, up to 20 times, to handle a VF reset request, using the return value of i40e_reset_vf as an indicator of whether the reset was successfully triggered. Currently, i40e_reset_vf always returns true, which causes new reset requests to be ignored if a different VF reset is already in progress. This patch updates the return value of i40e_reset_vf to reflect when another VF reset is in progress, allowing the caller to properly use the retry mechanism. Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF") Signed-off-by: Robert Malz Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 597b481ca1ce1a3b746d665deecedf5958f05eca Author: Martin Blumenstingl Date: Mon Jun 9 22:27:51 2025 +0200 drm/meson: fix more rounding issues with 59.94Hz modes [ Upstream commit 0cee6c4d3518b2e757aedae78771f17149f57653 ] Commit 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") attempts to resolve video playback using 59.94Hz. using YUV420 by changing the clock calculation to use Hz instead of kHz (thus yielding more precision). The basic calculation itself is correct, however the comparisions in meson_vclk_vic_supported_freq() and meson_vclk_setup() don't work anymore for 59.94Hz modes (using the freq * 1000 / 1001 logic). For example, drm/edid specifies a 593407kHz clock for 3840x2160@59.94Hz. With the mentioend commit we convert this to Hz. Then meson_vclk tries to find a matchig "params" entry (as the clock setup code currently only supports specific frequencies) by taking the venc_freq from the params and calculating the "alt frequency" (used for the 59.94Hz modes) from it, which is: (594000000Hz * 1000) / 1001 = 593406593Hz Similar calculation is applied to the phy_freq (TMDS clock), which is 10 times the pixel clock. Implement a new meson_vclk_freqs_are_matching_param() function whose purpose is to compare if the requested and calculated frequencies. They may not match exactly (for the reasons mentioned above). Allow the clocks to deviate slightly to make the 59.94Hz modes again. Fixes: 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") Reported-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250609202751.962208-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit bd27ff504e4d2ef94ea834d769a729ce85897ef3 Author: Martin Blumenstingl Date: Sat Jun 7 00:10:31 2025 +0200 drm/meson: use vclk_freq instead of pixel_freq in debug print [ Upstream commit faf2f8382088e8c74bd6eeb236c8c9190e61615e ] meson_vclk_vic_supported_freq() has a debug print which includes the pixel freq. However, within the whole function the pixel freq is irrelevant, other than checking the end of the params array. Switch to printing the vclk_freq which is being compared / matched against the inputs to the function to avoid confusion when analyzing error reports from users. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250606221031.3419353-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit f5d21eae4d7c3c1f861443365be99c7063f4b05c Author: Martin Blumenstingl Date: Fri Jun 6 22:37:29 2025 +0200 drm/meson: fix debug log statement when setting the HDMI clocks [ Upstream commit d17e61ab63fb7747b340d6a66bf1408cd5c6562b ] The "phy" and "vclk" frequency labels were swapped, making it more difficult to debug driver errors. Swap the label order to make them match with the actual frequencies printed to correct this. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250606203729.3311592-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 363e639977982308ee6ea99426f98e7a33204545 Author: Martin Blumenstingl Date: Mon Apr 21 22:13:00 2025 +0200 drm/meson: use unsigned long long / Hz for frequency types [ Upstream commit 1017560164b6bbcbc93579266926e6e96675262a ] Christian reports that 4K output using YUV420 encoding fails with the following error: Fatal Error, invalid HDMI vclk freq 593406 Modetest shows the following: 3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx, drm calculated value -------------------------------------^ This indicates that there's a (1kHz) mismatch between the clock calculated by the drm framework and the meson driver. Relevant function call stack: (drm framework) -> meson_encoder_hdmi_atomic_enable() -> meson_encoder_hdmi_set_vclk() -> meson_vclk_setup() The video clock requested by the drm framework is 593407kHz. This is passed by meson_encoder_hdmi_atomic_enable() to meson_encoder_hdmi_set_vclk() and the following formula is applied: - the frequency is halved (which would be 296703.5kHz) and rounded down to the next full integer, which is 296703kHz - TMDS clock is calculated (296703kHz * 10) - video encoder clock is calculated - this needs to match a table from meson_vclk.c and so it doubles the previously halved value again (resulting in 593406kHz) - meson_vclk_setup() can't find (either directly, or by deriving it from 594000kHz * 1000 / 1001 and rounding to the closest integer value - which is 593407kHz as originally requested by the drm framework) a matching clock in it's internal table and errors out with "invalid HDMI vclk freq" Fix the division precision by switching the whole meson driver to use unsigned long long (64-bit) Hz values for clock frequencies instead of unsigned int (32-bit) kHz to fix the rouding error. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Reported-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250421201300.778955-3-martin.blumenstingl@googlemail.com Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250421201300.778955-3-martin.blumenstingl@googlemail.com Stable-dep-of: d17e61ab63fb ("drm/meson: fix debug log statement when setting the HDMI clocks") Signed-off-by: Sasha Levin commit 7298df96179b3ee832717f7ef3bf035311bde736 Author: Haren Myneni Date: Tue Jun 10 07:42:27 2025 +0530 powerpc/vas: Return -EINVAL if the offset is non-zero in mmap() [ Upstream commit 0d67f0dee6c9176bc09a5482dd7346e3a0f14d0b ] The user space calls mmap() to map VAS window paste address and the kernel returns the complete mapped page for each window. So return -EINVAL if non-zero is passed for offset parameter to mmap(). See Documentation/arch/powerpc/vas-api.rst for mmap() restrictions. Co-developed-by: Jonathan Greental Signed-off-by: Jonathan Greental Reported-by: Jonathan Greental Fixes: dda44eb29c23 ("powerpc/vas: Add VAS user space API") Signed-off-by: Haren Myneni Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250610021227.361980-2-maddy@linux.ibm.com Signed-off-by: Sasha Levin commit 81260c41b518b6f32c701425f1427562fa92f293 Author: Ritesh Harjani (IBM) Date: Tue Jun 10 07:42:26 2025 +0530 powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap [ Upstream commit cd097df4596f3a1e9d75eb8520162de1eb8485b2 ] memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size. Reported-by: Jonathan Greental Fixes: 08a022ad3dfa ("powerpc/powernv/memtrace: Allow mmaping trace buffers") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250610021227.361980-1-maddy@linux.ibm.com Signed-off-by: Sasha Levin commit 5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72 Author: Eric Dumazet Date: Fri Jun 6 16:51:27 2025 +0000 net_sched: sch_sfq: fix a potential crash on gso_skb handling [ Upstream commit 82ffbe7776d0ac084031f114167712269bf3d832 ] SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. Tested: ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback") Reported-by: Marcus Wichelmann Closes: https://lore.kernel.org/netdev/9da42688-bfaa-4364-8797-e9271f3bdaef@hetzner-cloud.de/ Signed-off-by: Eric Dumazet Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250606165127.3629486-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75ad1ca646ee26d2a051bd84485ac3f99609ed2b Author: Alok Tiwari Date: Fri May 30 12:29:35 2025 -0700 scsi: iscsi: Fix incorrect error path labels for flashnode operations [ Upstream commit 9b17621366d210ffee83262a8754086ebbde5e55 ] Correct the error handling goto labels used when host lookup fails in various flashnode-related event handlers: - iscsi_new_flashnode() - iscsi_del_flashnode() - iscsi_login_flashnode() - iscsi_logout_flashnode() - iscsi_logout_flashnode_sid() scsi_host_put() is not required when shost is NULL, so jumping to the correct label avoids unnecessary operations. These functions previously jumped to the wrong goto label (put_host), which did not match the intended cleanup logic. Use the correct exit labels (exit_new_fnode, exit_del_fnode, etc.) to ensure proper error handling. Also remove the unused put_host label under iscsi_new_flashnode() as it is no longer needed. No functional changes beyond accurate error path correction. Fixes: c6a4bb2ef596 ("[SCSI] scsi_transport_iscsi: Add flash node mgmt support") Signed-off-by: Alok Tiwari Link: https://lore.kernel.org/r/20250530193012.3312911-1-alok.a.tiwari@oracle.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5c89dc8c3461c1396ce2385faa81ccbc1d514efb Author: Casey Connolly Date: Tue Mar 18 20:50:27 2025 +0000 ath10k: snoc: fix unbalanced IRQ enable in crash recovery [ Upstream commit 1650d32b92b01db03a1a95d69ee74fcbc34d4b00 ] In ath10k_snoc_hif_stop() we skip disabling the IRQs in the crash recovery flow, but we still unconditionally call enable again in ath10k_snoc_hif_start(). We can't check the ATH10K_FLAG_CRASH_FLUSH bit since it is cleared before hif_start() is called, so instead check the ATH10K_SNOC_FLAG_RECOVERY flag and skip enabling the IRQs during crash recovery. This fixes unbalanced IRQ enable splats that happen after recovering from a crash. Fixes: 0e622f67e041 ("ath10k: add support for WCN3990 firmware crash recovery") Signed-off-by: Caleb Connolly Tested-by: Loic Poulain Link: https://patch.msgid.link/20250318205043.1043148-1-caleb.connolly@linaro.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5d217e7031a5c06d366580fc6ddbf43527b780d4 Author: Jeongjun Park Date: Wed May 21 01:07:17 2025 +0900 ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() [ Upstream commit 87f7ce260a3c838b49e1dc1ceedf1006795157a2 ] There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking. Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Jeongjun Park Acked-by: Richard Cochran Link: https://patch.msgid.link/20250520160717.7350-1-aha310510@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f592eb12b43f21dbc972cbe583a12d256901e569 Author: Sanjeev Yadav Date: Fri May 23 13:14:01 2025 -0700 scsi: core: ufs: Fix a hang in the error handler [ Upstream commit 8a3514d348de87a9d5e2ac00fbac4faae0b97996 ] ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 Signed-off-by: Sanjeev Yadav [ bvanassche: rewrote patch description ] Fixes: 62694735ca95 ("[SCSI] ufs: Add runtime PM support for UFS host controller driver") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20250523201409.1676055-1-bvanassche@acm.org Reviewed-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5f30a81fc1887c9c5778a53aa87d03865862ee0f Author: Claudiu Beznea Date: Wed Jun 11 08:01:30 2025 +0300 serial: sh-sci: Clean sci_ports[0] after at earlycon exit commit 5f1017069933489add0c08659673443c9905659e upstream. The early_console_setup() function initializes sci_ports[0].port with an object of type struct uart_port obtained from the struct earlycon_device passed as an argument to early_console_setup(). Later, during serial port probing, the serial port used as earlycon (e.g., port A) might be remapped to a different position in the sci_ports[] array, and a different serial port (e.g., port B) might be assigned to slot 0. For example: sci_ports[0] = port B sci_ports[X] = port A In this scenario, the new port mapped at index zero (port B) retains the data associated with the earlycon configuration. Consequently, after the Linux boot process, any access to the serial port now mapped to sci_ports[0] (port B) will block the original earlycon port (port A). To address this, introduce an early_console_exit() function to clean up sci_ports[0] when earlycon is exited. To prevent the cleanup of sci_ports[0] while the serial device is still being used by earlycon, introduce the struct sci_port::probing flag and account for it in early_console_exit(). Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250116182249.3828577-5-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit b7f05abd60f01bf6f5bc03b83423a610a90dfd8c Author: Claudiu Beznea Date: Wed Jun 11 08:01:29 2025 +0300 serial: sh-sci: Move runtime PM enable to sci_probe_single() commit 239f11209e5f282e16f5241b99256e25dd0614b6 upstream. Relocate the runtime PM enable operation to sci_probe_single(). This change prepares the codebase for upcoming fixes. While at it, replace the existing logic with a direct call to devm_pm_runtime_enable() and remove sci_cleanup_single(). The devm_pm_runtime_enable() function automatically handles disabling runtime PM during driver removal. Reviewed-by: Geert Uytterhoeven Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250116182249.3828577-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 7857505af578d992f164643026da290c0ebbfbbb Author: Claudiu Beznea Date: Wed Jun 11 08:01:28 2025 +0300 serial: sh-sci: Check if TX data was written to device in .tx_empty() commit 7cc0e0a43a91052477c2921f924a37d9c3891f0c upstream. On the Renesas RZ/G3S, when doing suspend to RAM, the uart_suspend_port() is called. The uart_suspend_port() calls 3 times the struct uart_port::ops::tx_empty() before shutting down the port. According to the documentation, the struct uart_port::ops::tx_empty() API tests whether the transmitter FIFO and shifter for the port is empty. The Renesas RZ/G3S SCIFA IP reports the number of data units stored in the transmit FIFO through the FDR (FIFO Data Count Register). The data units in the FIFOs are written in the shift register and transmitted from there. The TEND bit in the Serial Status Register reports if the data was transmitted from the shift register. In the previous code, in the tx_empty() API implemented by the sh-sci driver, it is considered that the TX is empty if the hardware reports the TEND bit set and the number of data units in the FIFO is zero. According to the HW manual, the TEND bit has the following meaning: 0: Transmission is in the waiting state or in progress. 1: Transmission is completed. It has been noticed that when opening the serial device w/o using it and then switch to a power saving mode, the tx_empty() call in the uart_port_suspend() function fails, leading to the "Unable to drain transmitter" message being printed on the console. This is because the TEND=0 if nothing has been transmitted and the FIFOs are empty. As the TEND=0 has double meaning (waiting state, in progress) we can't determined the scenario described above. Add a software workaround for this. This sets a variable if any data has been sent on the serial console (when using PIO) or if the DMA callback has been called (meaning something has been transmitted). In the tx_empty() API the status of the DMA transaction is also checked and if it is completed or in progress the code falls back in checking the hardware registers instead of relying on the software variable. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20241125115856.513642-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman [claudiu.beznea: fixed conflict by: - keeping serial_port_out() instead of sci_port_out() in sci_transmit_chars() - keeping !uart_circ_empty(xmit) condition in sci_dma_tx_complete(), after s->tx_occurred = true; assignement] Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit e82d6c45db4f1c46f5186082c5315a202132bf28 Author: Judith Mendez Date: Tue Apr 29 12:30:08 2025 -0500 arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0 [ Upstream commit f55c9f087cc2e2252d44ffd9d58def2066fc176e ] For am65x, add missing ITAPDLYSEL values for Default Speed and High Speed SDR modes to sdhci0 node according to the device datasheet [0]. [0] https://www.ti.com/lit/gpn/am6548 Fixes: eac99d38f861 ("arm64: dts: ti: k3-am654-main: Update otap-del-sel values") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://lore.kernel.org/r/20250429173009.33994-1-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit c3b4bc986af517847ccf025bbcec93b8a5bcc21a Author: Judith Mendez Date: Tue Apr 23 10:17:28 2024 -0500 arm64: dts: ti: k3-am65-main: Fix sdhci node properties [ Upstream commit 8ffe9cb889f2b831a9d5bbb1f7ad42d30e31170f ] Update otap-del-sel properties as per datasheet [0]. Add missing clkbuf-sel and itap-del-sel values also as per datasheet [0]. Move clkbuf-sel and ti,trm-icp above the otap-del-sel properties so the sdhci nodes could be more uniform across platforms. [0] https://www.ti.com/lit/ds/symlink/am6548.pdf Fixes: eac99d38f861 ("arm64: dts: ti: k3-am654-main: Update otap-del-sel values") Fixes: d7600d070fb0 ("arm64: dts: ti: k3-am65-main: Add support for sdhci1") Signed-off-by: Judith Mendez Link: https://lore.kernel.org/r/20240423151732.3541894-2-jm@ti.com Signed-off-by: Nishanth Menon Stable-dep-of: f55c9f087cc2 ("arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0") Signed-off-by: Sasha Levin commit 29f0cd61d6b5a0e0156674ce3c3da28b42df0049 Author: Nishanth Menon Date: Wed Jun 7 08:20:42 2023 -0500 arm64: dts: ti: k3-am65-main: Drop deprecated ti,otap-del-sel property [ Upstream commit 2b9bb988742d1794e78d4297a99658f38477eedd ] ti,otap-del-sel has been deprecated in favor of ti,otap-del-sel-legacy. Drop the duplicate and misleading ti,otap-del-sel property. Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20230607132043.3932726-3-nm@ti.com Signed-off-by: Vignesh Raghavendra Stable-dep-of: f55c9f087cc2 ("arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0") Signed-off-by: Sasha Levin commit f3c2b179b413441300abfab03405ab5362ff2751 Author: Dmitry Torokhov Date: Mon May 5 15:49:59 2025 -0700 Input: synaptics-rmi - fix crash with unsupported versions of F34 [ Upstream commit ca39500f6af9cfe6823dc5aa8fbaed788d6e35b2 ] Sysfs interface for updating firmware for RMI devices is available even when F34 probe fails. The code checks for presence of F34 "container" pointer and then tries to use the function data attached to the sub-device. F34 assigns the function data early, before it knows if probe will succeed, leaving behind a stale pointer. Fix this by expanding checks to not only test for presence of F34 "container" but also check if there is driver data assigned to the sub-device, and call dev_set_drvdata() only after we are certain that probe is successful. This is not a complete fix, since F34 will be freed during firmware update, so there is still a race when fetching and accessing this pointer. This race will be addressed in follow-up changes. Reported-by: Hanno Böck Fixes: 29fd0ec2bdbe ("Input: synaptics-rmi4 - add support for F34 device reflash") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/aBlAl6sGulam-Qcx@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 17e5ca8ef81cdb9f042cc7b057355200103711fb Author: zhang songyi Date: Tue Sep 27 08:56:06 2022 -0700 Input: synaptics-rmi4 - convert to use sysfs_emit() APIs [ Upstream commit 9dedc915937c33302df7fcab01c45e7936d6195a ] Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Reported-by: Zeal Robot Signed-off-by: zhang songyi Link: https://lore.kernel.org/r/20220927070936.258300-1-zhang.songyi@zte.com.cn Signed-off-by: Dmitry Torokhov Stable-dep-of: ca39500f6af9 ("Input: synaptics-rmi - fix crash with unsupported versions of F34") Signed-off-by: Sasha Levin commit ef0c767a559b827b250951a8802d9c4d94cf4ff7 Author: Dan Carpenter Date: Thu May 8 09:29:23 2025 +0300 pmdomain: core: Fix error checking in genpd_dev_pm_attach_by_id() [ Upstream commit 0f5757667ec0aaf2456c3b76fcf0c6c3ea3591fe ] The error checking for of_count_phandle_with_args() does not handle negative error codes correctly. The problem is that "index" is a u32 so in the condition "if (index >= num_domains)" negative error codes stored in "num_domains" are type promoted to very high positive values and "index" is always going to be valid. Test for negative error codes first and then test if "index" is valid. Fixes: 3ccf3f0cd197 ("PM / Domains: Enable genpd_dev_pm_attach_by_id|name() for single PM domain") Signed-off-by: Dan Carpenter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/aBxPQ8AI8N5v-7rL@stanley.mountain Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 432a171d60056489270c462e651e6c3a13f855b1 Author: Al Viro Date: Wed Jun 4 12:27:08 2025 -0400 do_change_type(): refuse to operate on unmounted/not ours mounts [ Upstream commit 12f147ddd6de7382dad54812e65f3f08d05809fc ] Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2). Reviewed-by: Christian Brauner Fixes: 07b20889e305 ("beginning of the shared-subtree proper") Reported-by: "Orlando, Noah" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit eb34dc108e3ed6618fef932063fae76dba73d40b Author: Al Viro Date: Tue Jun 3 17:57:27 2025 -0400 fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2) [ Upstream commit d8cc0362f918d020ca1340d7694f07062dc30f36 ] 9ffb14ef61ba "move_mount: allow to add a mount into an existing group" breaks assertions on ->mnt_share/->mnt_slave. For once, the data structures in question are actually documented. Documentation/filesystem/sharedsubtree.rst: All vfsmounts in a peer group have the same ->mnt_master. If it is non-NULL, they form a contiguous (ordered) segment of slave list. do_set_group() puts a mount into the same place in propagation graph as the old one. As the result, if old mount gets events from somewhere and is not a pure event sink, new one needs to be placed next to the old one in the slave list the old one's on. If it is a pure event sink, we only need to make sure the new one doesn't end up in the middle of some peer group. "move_mount: allow to add a mount into an existing group" ends up putting the new one in the beginning of list; that's definitely not going to be in the middle of anything, so that's fine for case when old is not marked shared. In case when old one _is_ marked shared (i.e. is not a pure event sink), that breaks the assumptions of propagation graph iterators. Put the new mount next to the old one on the list - that does the right thing in "old is marked shared" case and is just as correct as the current behaviour if old is not marked shared (kudos to Pavel for pointing that out - my original suggested fix changed behaviour in the "nor marked" case, which complicated things for no good reason). Reviewed-by: Christian Brauner Fixes: 9ffb14ef61ba ("move_mount: allow to add a mount into an existing group") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 668923c474608dd9ebce0fbcc41bd8a27aa73dd6 Author: Ido Schimmel Date: Wed Jun 4 14:32:52 2025 +0300 seg6: Fix validation of nexthop addresses [ Upstream commit 7632fedb266d93ed0ed9f487133e6c6314a9b2d1 ] The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local lightweight tunnel") Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20250604113252.371528-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18e65229a328304a7ef59899a30fd34ad73ed56b Author: Mirco Barone Date: Thu Jun 5 14:06:16 2025 +0200 wireguard: device: enable threaded NAPI [ Upstream commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e ] Enable threaded NAPI by default for WireGuard devices in response to low performance behavior that we observed when multiple tunnels (and thus multiple wg devices) are deployed on a single host. This affects any kind of multi-tunnel deployment, regardless of whether the tunnels share the same endpoints or not (i.e., a VPN concentrator type of gateway would also be affected). The problem is caused by the fact that, in case of a traffic surge that involves multiple tunnels at the same time, the polling of the NAPI instance of all these wg devices tends to converge onto the same core, causing underutilization of the CPU and bottlenecking performance. This happens because NAPI polling is hosted by default in softirq context, but the WireGuard driver only raises this softirq after the rx peer queue has been drained, which doesn't happen during high traffic. In this case, the softirq already active on a core is reused instead of raising a new one. As a result, once two or more tunnel softirqs have been scheduled on the same core, they remain pinned there until the surge ends. In our experiments, this almost always leads to all tunnel NAPIs being handled on a single core shortly after a surge begins, limiting scalability to less than 3× the performance of a single tunnel, despite plenty of unused CPU cores being available. The proposed mitigation is to enable threaded NAPI for all WireGuard devices. This moves the NAPI polling context to a dedicated per-device kernel thread, allowing the scheduler to balance the load across all available cores. On our 32-core gateways, enabling threaded NAPI yields a ~4× performance improvement with 16 tunnels, increasing throughput from ~13 Gbps to ~48 Gbps. Meanwhile, CPU usage on the receiver (which is the bottleneck) jumps from 20% to 100%. We have found no performance regressions in any scenario we tested. Single-tunnel throughput remains unchanged. More details are available in our Netdev paper. Link: https://netdevconf.info/0x18/docs/netdev-0x18-paper23-talk-paper.pdf Signed-off-by: Mirco Barone Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld Link: https://patch.msgid.link/20250605120616.2808744-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5ad58285f9217d68cd5ea2ad86ce254a3fe7c4d Author: Florian Westphal Date: Fri May 23 14:20:44 2025 +0200 netfilter: nf_set_pipapo_avx2: fix initial map fill [ Upstream commit ea77c397bff8b6d59f6d83dae1425b08f465e8b5 ] If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh. Fixes: 791a615b7ad2 ("netfilter: nf_set_pipapo: fix initial map fill") Signed-off-by: Florian Westphal Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ae98a1787fdcb0096d122bc80d93c3c7d812c04b Author: Alok Tiwari Date: Mon Jun 2 03:34:29 2025 -0700 gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO [ Upstream commit 12c331b29c7397ac3b03584e12902990693bc248 ] gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Alok Tiwari Reviewed-by: Mina Almasry Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 277006dd681e140a6458e8de92e9d375afb7783e Author: Rafael J. Wysocki Date: Tue Jun 3 18:19:27 2025 +0200 PM: sleep: Fix power.is_suspended cleanup for direct-complete devices [ Upstream commit d46c4c839c20a599a0eb8d73708ce401f9c7d06d ] Commit 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors") caused power.is_suspended to be set for devices with power.direct_complete set, but it forgot to ensure the clearing of that flag for them in device_resume(), so power.is_suspended is still set for them during the next system suspend-resume cycle. If that cycle is aborted in dpm_suspend(), the subsequent invocation of dpm_resume() will trigger a device_resume() call for every device and because power.is_suspended is set for the devices in question, they will not be skipped by device_resume() as expected which causes scary error messages to be logged (as appropriate). To address this issue, move the clearing of power.is_suspended in device_resume() immediately after the power.is_suspended check so it will be always cleared for all devices processed by that function. Fixes: 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4280 Reported-and-tested-by: Chris Bainbridge Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/4990586.GXAFRqVoOG@rjwysocki.net Signed-off-by: Sasha Levin commit 61f418cd4ea5d56c60e093b2734fceaf912e2eba Author: Ronak Doshi Date: Fri May 30 15:27:00 2025 +0000 vmxnet3: correctly report gso type for UDP tunnels [ Upstream commit 982d30c30eaa2ec723df42e3bf526c014c1dbb88 ] Commit 3d010c8031e3 ("udp: do not accept non-tunnel GSO skbs landing in a tunnel") added checks in linux stack to not accept non-tunnel GRO packets landing in a tunnel. This exposed an issue in vmxnet3 which was not correctly reporting GRO packets for tunnel packets. This patch fixes this issue by setting correct GSO type for the tunnel packets. Currently, vmxnet3 does not support reporting inner fields for LRO tunnel packets. The issue is not seen for egress drivers that do not use skb inner fields. The workaround is to enable tnl-segmentation offload on the egress interfaces if the driver supports it. This problem pre-exists this patch fix and can be addressed as a separate future patch. Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by: Ronak Doshi Acked-by: Guolin Yang Link: https://patch.msgid.link/20250530152701.70354-1-ronak.doshi@broadcom.com [pabeni@redhat.com: dropped the changelog] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6ef8dfb1b68fc7e497fcb0138c1410fde492ef76 Author: Álvaro Fernández Rojas Date: Thu May 29 14:44:06 2025 +0200 net: dsa: tag_brcm: legacy: fix pskb_may_pull length [ Upstream commit efdddc4484859082da6c7877ed144c8121c8ea55 ] BRCM_LEG_PORT_ID was incorrectly used for pskb_may_pull length. The correct check is BRCM_LEG_TAG_LEN + VLAN_HLEN, or 10 bytes. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250529124406.2513779-1-noltari@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d94c6f53b0a742b76d70636d64a948de412d45ea Author: Michal Kubiak Date: Tue May 13 12:55:28 2025 +0200 ice: create new Tx scheduler nodes for new queues only [ Upstream commit 6fa2942578472c9cab13a8fc1dae0d830193e0a1 ] The current implementation of the Tx scheduler tree attempts to create nodes for all Tx queues, ignoring the fact that some queues may already exist in the tree. For example, if the VSI already has 128 Tx queues and the user requests for 16 new queues, the Tx scheduler will compute the tree for 272 queues (128 existing queues + 144 new queues), instead of 144 queues (128 existing queues and 16 new queues). Fix that by modifying the node count calculation algorithm to skip the queues that already exist in the tree. Fixes: 5513b920a4f7 ("ice: Update Tx scheduler tree for VSI multi-Tx queue support") Reviewed-by: Dawid Osuchowski Reviewed-by: Przemek Kitszel Reviewed-by: Jacob Keller Signed-off-by: Michal Kubiak Reviewed-by: Simon Horman Tested-by: Jesse Brandeburg Tested-by: Saritha Sanigani (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 96bc5ce57b16dfebaad0a7f32dbba789264ff3a5 Author: Luiz Augusto von Dentz Date: Wed May 28 14:53:11 2025 -0400 Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION [ Upstream commit 03dba9cea72f977e873e4e60e220fa596959dd8f ] Depending on the security set the response to L2CAP_LE_CONN_REQ shall be just L2CAP_CR_LE_ENCRYPTION if only encryption when BT_SECURITY_MEDIUM is selected since that means security mode 2 which doesn't require authentication which is something that is covered in the qualification test L2CAP/LE/CFC/BV-25-C. Link: https://github.com/bluez/bluez/issues/1270 Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receiving support") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 02f56169e6eb8d134f75d8a1f076412e48977a70 Author: Álvaro Fernández Rojas Date: Thu May 29 15:09:15 2025 +0200 spi: bcm63xx-hsspi: fix shared reset [ Upstream commit 3d6d84c8f2f66d3fd6a43a1e2ce8e6b54c573960 ] Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and HSSPI controllers, so reset shouldn't be exclusive. Fixes: 0eeadddbf09a ("spi: bcm63xx-hsspi: add reset support") Reported-by: Jonas Gorski Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250529130915.2519590-3-noltari@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bb9c9e989a80de415bc3598a3bef04f3abc94fb6 Author: Álvaro Fernández Rojas Date: Thu May 29 15:09:14 2025 +0200 spi: bcm63xx-spi: fix shared reset [ Upstream commit 5ad20e3d8cfe3b2e42bbddc7e0ebaa74479bb589 ] Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and HSSPI controllers, so reset shouldn't be exclusive. Fixes: 38807adeaf1e ("spi: bcm63xx-spi: add reset support") Reported-by: Jonas Gorski Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250529130915.2519590-2-noltari@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 417e17c44f3d5efb7a2fac8c193f3c4012ae7d53 Author: Dan Carpenter Date: Wed May 28 11:11:09 2025 +0300 net/mlx4_en: Prevent potential integer overflow calculating Hz [ Upstream commit 54d34165b4f786d7fea8412a18fb4a54c1eab623 ] The "freq" variable is in terms of MHz and "max_val_cycles" is in terms of Hz. The fact that "max_val_cycles" is a u64 suggests that support for high frequency is intended but the "freq_khz * 1000" would overflow the u32 type if we went above 4GHz. Use unsigned long long type for the mutliplication to prevent that. Fixes: 31c128b66e5b ("net/mlx4_en: Choose time-stamping shift value according to HW frequency") Signed-off-by: Dan Carpenter Reviewed-by: Simon Horman Link: https://patch.msgid.link/aDbFHe19juIJKjsb@stanley.mountain Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 605f09ae583e3fd34eb16bc194249ad012ea65fc Author: Yanqing Wang Date: Wed May 28 15:53:51 2025 +0800 driver: net: ethernet: mtk_star_emac: fix suspend/resume issue [ Upstream commit ba99c627aac85bc746fb4a6e2d79edb3ad100326 ] Identify the cause of the suspend/resume hang: netif_carrier_off() is called during link state changes and becomes stuck while executing linkwatch_work(). To resolve this issue, call netif_device_detach() during the Ethernet suspend process to temporarily detach the network device from the kernel and prevent the suspend/resume hang. Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Yanqing Wang Signed-off-by: Macpaul Lin Signed-off-by: Biao Huang Link: https://patch.msgid.link/20250528075351.593068-1-macpaul.lin@mediatek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e0b11227c4e8eb4bdf1b86aa8f0f3abb24e0f029 Author: Charalampos Mitrodimas Date: Tue May 27 16:35:44 2025 +0000 net: tipc: fix refcount warning in tipc_aead_encrypt [ Upstream commit f29ccaa07cf3d35990f4d25028cc55470d29372b ] syzbot reported a refcount warning [1] caused by calling get_net() on a network namespace that is being destroyed (refcount=0). This happens when a TIPC discovery timer fires during network namespace cleanup. The recently added get_net() call in commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") attempts to hold a reference to the network namespace. However, if the namespace is already being destroyed, its refcount might be zero, leading to the use-after-free warning. Replace get_net() with maybe_get_net(), which safely checks if the refcount is non-zero before incrementing it. If the namespace is being destroyed, return -ENODEV early, after releasing the bearer reference. [1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2 Reported-by: syzbot+f0c4a4aba757549ae26c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2 Fixes: e27902461713 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") Signed-off-by: Charalampos Mitrodimas Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20250527-net-tipc-warning-v2-1-df3dc398a047@posteo.net Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 54e7ce239d69874d02d48ec15327219a235c93e0 Author: Alok Tiwari Date: Tue May 27 06:08:16 2025 -0700 gve: Fix RX_BUFFERS_POSTED stat to report per-queue fill_cnt [ Upstream commit f41a94aade120dc60322865f363cee7865f2df01 ] Previously, the RX_BUFFERS_POSTED stat incorrectly reported the fill_cnt from RX queue 0 for all queues, resulting in inaccurate per-queue statistics. Fix this by correctly indexing priv->rx[idx].fill_cnt for each RX queue. Fixes: 24aeb56f2d38 ("gve: Add Gvnic stats AQ command and ethtool show/set-priv-flags.") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250527130830.1812903-1-alok.a.tiwari@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 28dd08343cc565c6be6b5b8ac991729a3f7abae4 Author: Quentin Schulz Date: Tue May 27 13:56:23 2025 +0200 net: stmmac: platform: guarantee uniqueness of bus_id [ Upstream commit eb7fd7aa35bfcc1e1fda4ecc42ccfcb526cdc780 ] bus_id is currently derived from the ethernetX alias. If one is missing for the device, 0 is used. If ethernet0 points to another stmmac device or if there are 2+ stmmac devices without an ethernet alias, then bus_id will be 0 for all of those. This is an issue because the bus_id is used to generate the mdio bus id (new_bus->id in drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c stmmac_mdio_register) and this needs to be unique. This allows to avoid needing to define ethernet aliases for devices with multiple stmmac controllers (such as the Rockchip RK3588) for multiple stmmac devices to probe properly. Obviously, the bus_id isn't guaranteed to be stable across reboots if no alias is set for the device but that is easily fixed by simply adding an alias if this is desired. Fixes: 25c83b5c2e82 ("dt:net:stmmac: Add support to dwmac version 3.610 and 3.710") Signed-off-by: Quentin Schulz Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20250527-stmmac-mdio-bus_id-v2-1-a5ca78454e3c@cherry.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dae5b88185938bd3c2f2a0b93519fec29cc549c5 Author: Nicolas Pitre Date: Thu May 15 11:30:52 2025 -0400 vt: remove VT_RESIZE and VT_RESIZEX from vt_compat_ioctl() [ Upstream commit c4c7ead7b86c1e7f11c64915b7e5bb6d2e242691 ] They are listed amon those cmd values that "treat 'arg' as an integer" which is wrong. They should instead fall into the default case. Probably nobody ever relied on that code since 2009 but still. Fixes: e92166517e3c ("tty: handle VT specific compat ioctls in vt driver") Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/pr214s15-36r8-6732-2pop-159nq85o48r7@syhkavp.arg Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 38c5712df50d1b490590bf256f51e29158133c7a Author: WangYuli Date: Wed Apr 16 11:45:48 2025 +0800 MIPS: Loongson64: Add missing '#interrupt-cells' for loongson64c_ls7a [ Upstream commit 6d223b8ffcd1593d032b71875def2daa71c53111 ] Similar to commit 98a9e2ac3755 ("MIPS: Loongson64: DTS: Fix msi node for ls7a"). Fix follow warnings: arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts:28.31-36.4: Warning (interrupt_provider): /bus@10000000/msi-controller@2ff00000: Missing '#interrupt-cells' in interrupt provider arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider' Fixes: 24af105962c8 ("MIPS: Loongson64: DeviceTree for LS7A PCH") Tested-by: WangYuli Signed-off-by: WangYuli Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 2659abc74cb303177b739933b316225027b25a84 Author: Uwe Kleine-König Date: Mon Mar 17 12:52:47 2025 +0100 iio: adc: ad7124: Fix 3dB filter frequency reading [ Upstream commit 8712e4986e7ce42a14c762c4c350f290989986a5 ] The sinc4 filter has a factor 0.23 between Output Data Rate and f_{3dB} and for sinc3 the factor is 0.272 according to the data sheets for ad7124-4 (Rev. E.) and ad7124-8 (Rev. F). Fixes: cef2760954cf ("iio: adc: ad7124: add 3db filter") Signed-off-by: Uwe Kleine-König Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250317115247.3735016-6-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 19fd9f5a69363d33079097d866eb6082d61bf31d Author: Henry Martin Date: Thu Apr 3 15:03:39 2025 +0800 serial: Fix potential null-ptr-deref in mlb_usio_probe() [ Upstream commit 86bcae88c9209e334b2f8c252f4cc66beb261886 ] devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. Fixes: ba44dc043004 ("serial: Add Milbeaut serial control") Signed-off-by: Henry Martin Link: https://lore.kernel.org/r/20250403070339.64990-1-bsdhenrymartin@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a1e16a6cbf4452b46f20b862d6141a1e90844ee Author: Lad Prabhakar Date: Mon Apr 7 11:50:02 2025 +0100 usb: renesas_usbhs: Reorder clock handling and power management in probe [ Upstream commit ffb34a60ce86656ba12d46e91f1ccc71dd221251 ] Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]--- Fixes: f1407d5c66240 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Lad Prabhakar Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20250407105002.107181-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6c1344a5bb1c653018d3e5448aac6a2aa1b3dbb5 Author: Bjorn Helgaas Date: Thu May 22 18:21:07 2025 -0500 PCI/DPC: Initialize aer_err_info before using it [ Upstream commit a424b598e6a6c1e69a2bb801d6fd16e805ab2c38 ] Previously the struct aer_err_info "info" was allocated on the stack without being initialized, so it contained junk except for the fields we explicitly set later. Initialize "info" at declaration so it starts as all zeros. Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling") Signed-off-by: Bjorn Helgaas Tested-by: Krzysztof Wilczyński Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Ilpo Järvinen Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20250522232339.1525671-2-helgaas@kernel.org Signed-off-by: Sasha Levin commit 9f133e04c62246353b8b1f0a679535c65161ebcf Author: Henry Martin Date: Wed Apr 2 10:39:00 2025 +0800 dmaengine: ti: Add NULL check in udma_probe() [ Upstream commit fd447415e74bccd7362f760d4ea727f8e1ebfe91 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA") Signed-off-by: Henry Martin Reviewed-by: Nathan Lynch Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20250402023900.43440-1-bsdhenrymartin@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3e7061f62bd70fa98db80f18dbfeb23fbe6048ee Author: Hans Zhang <18255117159@163.com> Date: Sat Apr 19 21:30:58 2025 +0800 PCI: cadence: Fix runtime atomic count underflow [ Upstream commit 8805f32a96d3b97cef07999fa6f52112678f7e65 ] If the call to pci_host_probe() in cdns_pcie_host_setup() fails, PM runtime count is decremented in the error path using pm_runtime_put_sync(). But the runtime count is not incremented by this driver, but only by the callers (cdns_plat_pcie_probe/j721e_pcie_probe). And the callers also decrement the runtime PM count in their error path. So this leads to the below warning from the PM core: "runtime PM usage count underflow!" So fix it by getting rid of pm_runtime_put_sync() in the error path and directly return the errno. Fixes: 49e427e6bdd1 ("Merge branch 'pci/host-probe-refactor'") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250419133058.162048-1-18255117159@163.com Signed-off-by: Sasha Levin commit 19f0d83e1450a1a7587822589ccd6bde279999a6 Author: Wolfram Sang Date: Thu Feb 27 14:42:56 2025 +0100 rtc: sh: assign correct interrupts with DT [ Upstream commit 8f2efdbc303fe7baa83843d3290dd6ea5ba3276c ] The DT bindings for this driver define the interrupts in the order as they are numbered in the interrupt controller. The old platform_data, however, listed them in a different order. So, for DT based platforms, they are mixed up. Assign them specifically for DT, so we can keep the bindings stable. After the fix, 'rtctest' passes again on the Renesas Genmai board (RZ-A1 / R7S72100). Fixes: dab5aec64bf5 ("rtc: sh: add support for rza series") Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20250227134256.9167-11-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 92270f14a8c1f0cceab8fe9c404a3cb0140056d0 Author: Li Lingfeng Date: Tue Mar 4 21:05:33 2025 +0800 nfs: ignore SB_RDONLY when remounting nfs [ Upstream commit 80c4de6ab44c14e910117a02f2f8241ffc6ec54a ] In some scenarios, when mounting NFS, more than one superblock may be created. The final superblock used is the last one created, but only the first superblock carries the ro flag passed from user space. If a ro flag is added to the superblock via remount, it will trigger the issue described in Link[1]. Link[2] attempted to address this by marking the superblock as ro during the initial mount. However, this introduced a new problem in scenarios where multiple mount points share the same superblock: [root@a ~]# mount /dev/sdb /mnt/sdb [root@a ~]# echo "/mnt/sdb *(rw,no_root_squash)" > /etc/exports [root@a ~]# echo "/mnt/sdb/test_dir2 *(ro,no_root_squash)" >> /etc/exports [root@a ~]# systemctl restart nfs-server [root@a ~]# mount -t nfs -o rw 127.0.0.1:/mnt/sdb/test_dir1 /mnt/test_mp1 [root@a ~]# mount | grep nfs4 127.0.0.1:/mnt/sdb/test_dir1 on /mnt/test_mp1 type nfs4 (rw,relatime,... [root@a ~]# mount -t nfs -o ro 127.0.0.1:/mnt/sdb/test_dir2 /mnt/test_mp2 [root@a ~]# mount | grep nfs4 127.0.0.1:/mnt/sdb/test_dir1 on /mnt/test_mp1 type nfs4 (ro,relatime,... 127.0.0.1:/mnt/sdb/test_dir2 on /mnt/test_mp2 type nfs4 (ro,relatime,... [root@a ~]# When mounting the second NFS, the shared superblock is marked as ro, causing the previous NFS mount to become read-only. To resolve both issues, the ro flag is no longer applied to the superblock during remount. Instead, the ro flag on the mount is used to control whether the mount point is read-only. Fixes: 281cad46b34d ("NFS: Create a submount rpc_op") Link[1]: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/ Link[2]: https://lore.kernel.org/all/20241130035818.1459775-1-lilingfeng3@huawei.com/ Signed-off-by: Li Lingfeng Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 3293cc4625183ef689cacf26b300d2e58a030674 Author: Li Lingfeng Date: Tue Mar 4 21:05:32 2025 +0800 nfs: clear SB_RDONLY before getting superblock [ Upstream commit 8cd9b785943c57a136536250da80ba1eb6f8eb18 ] As described in the link, commit 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs") removed the check for the ro flag when determining whether to share the superblock, which caused issues when mounting different subdirectories under the same export directory via NFSv3. However, this change did not affect NFSv4. For NFSv3: 1) A single superblock is created for the initial mount. 2) When mounted read-only, this superblock carries the SB_RDONLY flag. 3) Before commit 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs"): Subsequent rw mounts would not share the existing ro superblock due to flag mismatch, creating a new superblock without SB_RDONLY. After the commit: The SB_RDONLY flag is ignored during superblock comparison, and this leads to sharing the existing superblock even for rw mounts. Ultimately results in write operations being rejected at the VFS layer. For NFSv4: 1) Multiple superblocks are created and the last one will be kept. 2) The actually used superblock for ro mounts doesn't carry SB_RDONLY flag. Therefore, commit 52cb7f8f1778 doesn't affect NFSv4 mounts. Clear SB_RDONLY before getting superblock when NFS_MOUNT_UNSHARED is not set to fix it. Fixes: 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs") Closes: https://lore.kernel.org/all/12d7ea53-1202-4e21-a7ef-431c94758ce5@app.fastmail.com/T/ Signed-off-by: Li Lingfeng Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 477c4882e53e0a9218d5aa3f398e13e6977dde98 Author: Dapeng Mi Date: Thu Apr 3 06:08:10 2025 +0000 perf record: Fix incorrect --user-regs comments [ Upstream commit a4a859eb6704a8aa46aa1cec5396c8d41383a26b ] The comment of "--user-regs" option is not correct, fix it. "on interrupt," -> "in user space," Fixes: 84c417422798c897 ("perf record: Support direct --user-regs arguments") Reviewed-by: Ian Rogers Signed-off-by: Dapeng Mi Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250403060810.196028-1-dapeng1.mi@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 00b96ed79bce64e4ad3daa8dff9a1beb8bf53559 Author: Leo Yan Date: Mon Mar 31 18:27:59 2025 +0100 perf tests switch-tracking: Fix timestamp comparison [ Upstream commit 628e124404b3db5e10e17228e680a2999018ab33 ] The test might fail on the Arm64 platform with the error: # perf test -vvv "Track with sched_switch" Missing sched_switch events # The issue is caused by incorrect handling of timestamp comparisons. The comparison result, a signed 64-bit value, was being directly cast to an int, leading to incorrect sorting for sched events. The case does not fail everytime, usually I can trigger the failure after run 20 ~ 30 times: # while true; do perf test "Track with sched_switch"; done 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : FAILED! 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : FAILED! 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok I used cross compiler to build Perf tool on my host machine and tested on Debian / Juno board. Generally, I think this issue is not very specific to GCC versions. As both internal CI and my local env can reproduce the issue. My Host Build compiler: # aarch64-linux-gnu-gcc --version aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 Juno Board: # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Fix this by explicitly returning 0, 1, or -1 based on whether the result is zero, positive, or negative. Fixes: d44bc558297222d9 ("perf tests: Add a test for tracking with sched_switch") Reviewed-by: Ian Rogers Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: James Clark Cc: Kan Liang Cc: Namhyung Kim Link: https://lore.kernel.org/r/20250331172759.115604-1-leo.yan@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f93ea1e5e18568f7ad040afbdf037fa4b9b8f440 Author: Alexey Gladkov Date: Sat Apr 26 18:16:32 2025 +0200 mfd: stmpe-spi: Correct the name used in MODULE_DEVICE_TABLE [ Upstream commit 59d60c16ed41475f3b5f7b605e75fbf8e3628720 ] The name used in the macro does not exist. drivers/mfd/stmpe-spi.c:132:26: error: use of undeclared identifier 'stmpe_id' 132 | MODULE_DEVICE_TABLE(spi, stmpe_id); Fixes: e789995d5c61 ("mfd: Add support for STMPE SPI interface") Signed-off-by: Alexey Gladkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/79d5a847303e45a46098f2d827d3d8a249a32be3.1745591072.git.legion@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f79f8d8dda3ae1696514e7c399fa7e90be21f72d Author: Christophe JAILLET Date: Mon Apr 21 17:00:34 2025 +0200 mfd: exynos-lpass: Avoid calling exynos_lpass_disable() twice in exynos_lpass_remove() [ Upstream commit b70b84556eeca5262d290e8619fe0af5b7664a52 ] exynos_lpass_disable() is called twice in the remove function. Remove one of these calls. Fixes: 90f447170c6f ("mfd: exynos-lpass: Add runtime PM support") Signed-off-by: Christophe JAILLET Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/74d69e8de10308c9855db6d54155a3de4b11abfd.1745247209.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e009779acc0448dd459a21347a33d2f508543f52 Author: Dan Carpenter Date: Wed Apr 23 20:22:05 2025 +0300 rpmsg: qcom_smd: Fix uninitialized return variable in __qcom_smd_send() [ Upstream commit 5de775df3362090a6e90046d1f2d83fe62489aa0 ] The "ret" variable isn't initialized if we don't enter the loop. For example, if "channel->state" is not SMD_CHANNEL_OPENED. Fixes: 33e3820dda88 ("rpmsg: smd: Use spinlock in tx path") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/aAkhvV0nSbrsef1P@stanley.mountain Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e8461ec67a36c356a00f2b94bd57e8f0ff5824dc Author: Dan Carpenter Date: Wed Apr 2 13:59:51 2025 +0300 remoteproc: qcom_wcnss_iris: Add missing put_device() on error in probe [ Upstream commit 0cb4b1b97041d8a1f773425208ded253c1cb5869 ] The device_del() call matches with the device_add() but we also need to call put_device() to trigger the qcom_iris_release(). Fixes: 1fcef985c8bd ("remoteproc: qcom: wcnss: Fix race with iris probe") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/4604f7e0-3217-4095-b28a-3ff8b5afad3a@stanley.mountain Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8d39a6fd984309d4eb2cdb48d0d1484748f48de3 Author: Adrian Hunter Date: Mon May 12 12:39:32 2025 +0300 perf scripts python: exported-sql-viewer.py: Fix pattern matching with Python 3 [ Upstream commit 17e548405a81665fd14cee960db7d093d1396400 ] The script allows the user to enter patterns to find symbols. The pattern matching characters are converted for use in SQL. For PostgreSQL the conversion involves using the Python maketrans() method which is slightly different in Python 3 compared with Python 2. Fix to work in Python 3. Fixes: beda0e725e5f06ac ("perf script python: Add Python3 support to exported-sql-viewer.py") Signed-off-by: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Tony Jones Link: https://lore.kernel.org/r/20250512093932.79854-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9d06ac32c202142da40904180f2669ed4f5073ac Author: Henry Martin Date: Tue Apr 1 17:16:47 2025 +0800 backlight: pm8941: Add NULL check in wled_configure() [ Upstream commit e12d3e1624a02706cdd3628bbf5668827214fa33 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name") Signed-off-by: Henry Martin Reviewed-by: Dmitry Baryshkov Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250401091647.22784-1-bsdhenrymartin@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 07a4014cc66b7cf6cfaa1fffa38d7aef62cbaa19 Author: Arnaldo Carvalho de Melo Date: Wed Apr 9 21:58:19 2025 -0300 perf ui browser hists: Set actions->thread before calling do_zoom_thread() [ Upstream commit 1741189d843a1d5ef38538bc52a3760e2e46cb2e ] In 7cecb7fe8388d5c3 ("perf hists: Move sort__has_comm into struct perf_hpp_list") it assumes that act->thread is set prior to calling do_zoom_thread(). This doesn't happen when we use ESC or the Left arrow key to Zoom out of a specific thread, making this operation not to work and we get stuck into the thread zoom. In 6422184b087ff435 ("perf hists browser: Simplify zooming code using pstack_peek()") it says no need to set actions->thread, and at that point that was true, but in 7cecb7fe8388d5c3 a actions->thread == NULL check was added before the zoom out of thread could kick in. We can zoom out using the alternative 't' thread zoom toggle hotkey to finally set actions->thread before calling do_zoom_thread() and zoom out, but lets also fix the ESC/Zoom out of thread case. Fixes: 7cecb7fe8388d5c3 ("perf hists: Move sort__has_comm into struct perf_hpp_list") Reported-by: Ingo Molnar Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Ian Rogers Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit c6dbaf7e31cbbe82a6d4c880b3a06445f1f81f7e Author: Arnaldo Carvalho de Melo Date: Tue Apr 8 11:37:20 2025 -0300 perf build: Warn when libdebuginfod devel files are not available [ Upstream commit 4fce4b91fd1aabb326c46e237eb4b19ab72598f8 ] While working on 'perf version --build-options' I noticed that: $ perf version --build-options perf version 6.15.rc1.g312a07a00d31 aio: [ on ] # HAVE_AIO_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT bpf_skeletons: [ on ] # HAVE_BPF_SKEL debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT And looking at tools/perf/Makefile.config I also noticed that it is not opt-in, meaning we will attempt to build with it in all normal cases. So add the usual warning at build time to let the user know that something recommended is missing, now we see: Makefile.config:563: No elfutils/debuginfod.h found, no debuginfo server support, please install elfutils-debuginfod-client-devel or equivalent And after following the recommendation: $ perf check feature debuginfod debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT $ ldd ~/bin/perf | grep debuginfo libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007fee5cf5f000) $ With this feature on several perf tools will fetch what is needed and not require all the contents of the debuginfo packages, for instance: # rpm -qa | grep kernel-debuginfo # pahole --running_kernel_vmlinux pahole: couldn't find a vmlinux that matches the running kernel HINT: Maybe you're inside a container or missing a debuginfo package? # # perf trace -e open* perf probe --vars icmp_rcv 0.000 ( 0.005 ms): perf/97391 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC) = 3 0.014 ( 0.004 ms): perf/97391 openat(dfd: CWD, filename: "/lib64/libm.so.6", flags: RDONLY|CLOEXEC) = 3 32130.100 ( 0.008 ms): perf/97391 openat(dfd: CWD, filename: "/root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo") = 3 Available variables at icmp_rcv @ struct sk_buff* skb # # pahole --running_kernel_vmlinux /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # file /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aa3c82b4a13f9c0e0301bebb20fe958c4db6f362, with debug_info, not stripped # ls -la /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo -r--------. 1 root root 475401512 Mar 27 21:00 /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # Then, cached: # perf stat --null perf probe --vars icmp_rcv Available variables at icmp_rcv @ struct sk_buff* skb Performance counter stats for 'perf probe --vars icmp_rcv': 0.671389041 seconds time elapsed 0.519176000 seconds user 0.150860000 seconds sys Fixes: c7a14fdcb3fa7736 ("perf build-ids: Fall back to debuginfod query if debuginfo not found") Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Dmitriy Vyukov Cc: Howard Chu Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Frank Ch. Eigler Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com [ Folded patch from Ingo to have the debian/ubuntu devel package added build warning message ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2d63433e8eaa3c91b2948190e395bc67009db0d9 Author: Sergey Shtylyov Date: Wed May 14 23:35:58 2025 +0300 fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() [ Upstream commit 3f6dae09fc8c306eb70fdfef70726e1f154e173a ] In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 96fe6a2109db ("[PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support") Signed-off-by: Sergey Shtylyov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 1fd889c145722579aa038c31cbc07cfdd4d75166 Author: Henry Martin Date: Thu May 15 16:00:44 2025 +0930 soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() [ Upstream commit f1706e0e1a74b095cbc60375b9b1e6205f5f4c98 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250401074647.21300-1-bsdhenrymartin@gmail.com [arj: Fix Fixes: tag to use subject from 3772e5da4454] Signed-off-by: Andrew Jeffery Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 0fab016dc4aaefcc89550563f75ea504dcc5d0b5 Author: Su Hui Date: Thu May 15 16:00:43 2025 +0930 soc: aspeed: lpc: Fix impossible judgment condition [ Upstream commit d9f0a97e859bdcef51f9c187b1eb712eb13fd3ff ] smatch error： drivers/soc/aspeed/aspeed-lpc-snoop.c:169 aspeed_lpc_snoop_config_irq() warn: platform_get_irq() does not return zero platform_get_irq() return non-zero IRQ number or negative error code, change '!lpc_snoop->irq' to 'lpc_snoop->irq < 0' to fix this. Fixes: 9f4f9ae81d0a ("drivers/misc: add Aspeed LPC snoop driver") Signed-off-by: Su Hui Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20231027020703.1231875-1-suhui@nfschina.com Signed-off-by: Andrew Jeffery Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 3a2249e91547aa1f2f4738344f7b2b7cd327b25b Author: Quentin Schulz Date: Fri Apr 25 17:18:10 2025 +0200 arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399 Puma with Haikou [ Upstream commit febd8c6ab52c683b447fe22fc740918c86feae43 ] The u2phy0_host port is the part of the USB PHY0 (namely the HOST0_DP/DM lanes) which routes directly to the USB2.0 HOST controller[1]. The other lanes of the PHY are routed to the USB3.0 OTG controller (dwc3), which we do use. The HOST0_DP/DM lanes aren't routed on RK3399 Puma so let's simply disable the USB2.0 controllers. USB3 OTG has been known to be unstable on RK3399 Puma Haikou for a while, one of the recurring issues being that only USB2 is detected and not USB3 in host mode. Reading the justification above and seeing that we are keeping u2phy0_host in the Haikou carrierboard DTS probably may have bothered you since it should be changed to u2phy0_otg. The issue is that if it's switched to that, USB OTG on Haikou is entirely broken. I have checked the routing in the Gerber file, the lanes are going to the expected ball pins (that is, NOT HOST0_DP/DM). u2phy0_host is for sure the wrong part of the PHY to use, but it's the only one that works at the moment for that board so keep it until we figure out what exactly is broken. No intended functional change. [1] https://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf Chapter 2 USB2.0 PHY Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Quentin Schulz Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-5-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 26e868438691feeac05f072363a8909e493e72f6 Author: Dmitry Baryshkov Date: Tue Mar 18 15:22:00 2025 +0200 ARM: dts: qcom: apq8064 merge hw splinlock into corresponding syscon device [ Upstream commit 325c6a441ae1f8fcb1db9bb945b8bdbd3142141e ] Follow up the expected way of describing the SFPB hwspinlock and merge hwspinlock node into corresponding syscon node, fixing several dt-schema warnings. Fixes: 24a9baf933dc ("ARM: dts: qcom: apq8064: Add hwmutex and SMEM nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-7-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7002b954c4a8b9965ba0f139812ee4a6f71beac8 Author: Ioana Ciornei Date: Tue Apr 8 13:58:09 2025 +0300 bus: fsl-mc: fix double-free on mc_dev [ Upstream commit d694bf8a9acdbd061596f3e7549bc8cb70750a60 ] The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus); Fixes: a042fbed0290 ("staging: fsl-mc: simplify couple of deallocations") Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250408105814.2837951-2-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Sasha Levin commit 1ce784ddfb31502add4f51ee481ec27d1cbaefa5 Author: Ryusuke Konishi Date: Tue Apr 29 02:37:08 2025 +0900 nilfs2: do not propagate ENOENT error from nilfs_btree_propagate() [ Upstream commit 8e39fbb1edbb4ec9d7c1124f403877fc167fcecd ] In preparation for writing logs, in nilfs_btree_propagate(), which makes parent and ancestor node blocks dirty starting from a modified data block or b-tree node block, if the starting block does not belong to the b-tree, i.e. is isolated, nilfs_btree_do_lookup() called within the function fails with -ENOENT. In this case, even though -ENOENT is an internal code, it is propagated to the log writer via nilfs_bmap_propagate() and may be erroneously returned to system calls such as fsync(). Fix this issue by changing the error code to -EINVAL in this case, and having the bmap layer detect metadata corruption and convert the error code appropriately. Link: https://lkml.kernel.org/r/20250428173808.6452-3-konishi.ryusuke@gmail.com Fixes: 1f5abe7e7dbc ("nilfs2: replace BUG_ON and BUG calls triggerable from ioctl") Signed-off-by: Ryusuke Konishi Cc: Wentao Liang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c155d46ff02cec4db10fbd05cf665e280e2a3a52 Author: Wentao Liang Date: Tue Apr 29 02:37:07 2025 +0900 nilfs2: add pointer check for nilfs_direct_propagate() [ Upstream commit f43f02429295486059605997bc43803527d69791 ] Patch series "nilfs2: improve sanity checks in dirty state propagation". This fixes one missed check for block mapping anomalies and one improper return of an error code during a preparation step for log writing, thereby improving checking for filesystem corruption on writeback. This patch (of 2): In nilfs_direct_propagate(), the printer get from nilfs_direct_get_ptr() need to be checked to ensure it is not an invalid pointer. If the pointer value obtained by nilfs_direct_get_ptr() is NILFS_BMAP_INVALID_PTR, means that the metadata (in this case, i_bmap in the nilfs_inode_info struct) that should point to the data block at the buffer head of the argument is corrupted and the data block is orphaned, meaning that the file system has lost consistency. Add a value check and return -EINVAL when it is an invalid pointer. Link: https://lkml.kernel.org/r/20250428173808.6452-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20250428173808.6452-2-konishi.ryusuke@gmail.com Fixes: 36a580eb489f ("nilfs2: direct block mapping") Signed-off-by: Wentao Liang Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 1a955db411317d007bc9b8d9e4aaca2d4ad84e13 Author: Murad Masimov Date: Wed Apr 2 09:56:27 2025 +0300 ocfs2: fix possible memory leak in ocfs2_finish_quota_recovery [ Upstream commit cdc3ed3035d0fe934aa1d9b78ce256752fd3bb7d ] If ocfs2_finish_quota_recovery() exits due to an error before passing all rc_list elements to ocfs2_recover_local_quota_file() then it can lead to a memory leak as rc_list may still contain elements that have to be freed. Release all memory allocated by ocfs2_add_recovery_chunk() using ocfs2_free_quota_recovery() instead of kfree(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Link: https://lkml.kernel.org/r/20250402065628.706359-2-m.masimov@mt-integration.ru Fixes: 2205363dce74 ("ocfs2: Implement quota recovery") Signed-off-by: Murad Masimov Reviewed-by: Jan Kara Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5c51aa862cbeed2f3887f0382a2708956710bd68 Author: Phillip Lougher Date: Wed Apr 9 03:47:47 2025 +0100 Squashfs: check return result of sb_min_blocksize [ Upstream commit 734aa85390ea693bb7eaf2240623d41b03705c84 ] Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize(). Link: https://lkml.kernel.org/r/20250409024747.876480-1-phillip@squashfs.org.uk Fixes: 0aa666190509 ("Squashfs: super block operations") Reported-by: syzbot+65761fc25a137b9c8c6e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67f0dd7a.050a0220.0a13.0230.GAE@google.com/ Signed-off-by: Phillip Lougher Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ca87e905ff3c01f4795c1a04ba815d46fc2842f1 Author: Adam Ford Date: Tue Apr 15 20:01:28 2025 -0500 arm64: dts: imx8mn-beacon: Fix RTC capacitive load [ Upstream commit c3f03bec30efd5082b55876846d57b5d17dae7b9 ] Although not noticeable when used every day, the RTC appears to drift when left to sit over time. This is due to the capacitive load not being properly set. Fix RTC drift by correcting the capacitive load setting from 7000 to 12500, which matches the actual hardware configuration. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 485f23661881b01ca07b09f2d2686461ab3b4529 Author: Adam Ford Date: Tue Apr 15 20:01:27 2025 -0500 arm64: dts: imx8mm-beacon: Fix RTC capacitive load [ Upstream commit 2e98d456666d63f897ba153210bcef9d78ba0f3a ] Although not noticeable when used every day, the RTC appears to drift when left to sit over time. This is due to the capacitive load not being properly set. Fix RTC drift by correcting the capacitive load setting from 7000 to 12500, which matches the actual hardware configuration. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d274c13729262381f518984985ba8f724e59d511 Author: Wolfram Sang Date: Wed Apr 2 23:04:46 2025 +0200 ARM: dts: at91: at91sam9263: fix NAND chip selects [ Upstream commit c72ede1c24be689733bcd2233a3a56f2478429c8 ] NAND did not work on my USB-A9263. I discovered that the offending commit converted the PIO bank for chip selects wrongly, so all A9263 boards need to be fixed. Fixes: 1004a2977bdc ("ARM: dts: at91: Switch to the new NAND bindings") Signed-off-by: Wolfram Sang Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20250402210446.5972-2-wsa+renesas@sang-engineering.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit dac5dfede03f1731de9971f3e99764e187b25641 Author: Wolfram Sang Date: Fri Apr 4 13:27:43 2025 +0200 ARM: dts: at91: usb_a9263: fix GPIO for Dataflash chip select [ Upstream commit 67ba341e57ab158423818ed33bfa1c40eb0e5e7e ] Dataflash did not work on my board. After checking schematics and using the proper GPIO, it works now. Also, make it active low to avoid: flash@0 enforce active low on GPIO handle Fixes: 2432d201468d ("ARM: at91: dt: usb-a9263: add dataflash support") Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20250404112742.67416-2-wsa+renesas@sang-engineering.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 8636cafb2c6778b90ad1c5d14ade2bc3c66a77b0 Author: Zhiguo Niu Date: Wed May 14 16:45:49 2025 +0800 f2fs: fix to correct check conditions in f2fs_cross_rename [ Upstream commit 9883494c45a13dc88d27dde4f988c04823b42a2f ] Should be "old_dir" here. Fixes: 5c57132eaf52 ("f2fs: support project quota") Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e61079985c54e8f93841d11a53bf23fde51c1264 Author: Zhiguo Niu Date: Wed May 14 16:45:48 2025 +0800 f2fs: use d_inode(dentry) cleanup dentry->d_inode [ Upstream commit a6c397a31f58a1d577c2c8d04b624e9baa31951c ] no logic changes. Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 92dd2d870e7b63efa210d1513d89dd5152bb83e2 Author: Horatiu Vultur Date: Fri May 23 10:27:16 2025 +0200 net: phy: mscc: Stop clearing the the UDPv4 checksum for L2 frames [ Upstream commit 57a92d14659df3e7e7e0052358c8cc68bbbc3b5e ] We have noticed that when PHY timestamping is enabled, L2 frames seems to be modified by changing two 2 bytes with a value of 0. The place were these 2 bytes seems to be random(or I couldn't find a pattern). In most of the cases the userspace can ignore these frames but if for example those 2 bytes are in the correction field there is nothing to do. This seems to happen when configuring the HW for IPv4 even that the flow is not enabled. These 2 bytes correspond to the UDPv4 checksum and once we don't enable clearing the checksum when using L2 frames then the frame doesn't seem to be changed anymore. Fixes: 7d272e63e0979d ("net: phy: mscc: timestamping and PHC support") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250523082716.2935895-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ad17eb86d042d72a59fd184ad1adf34f5eb36843 Author: Faicker Mo Date: Fri May 23 03:41:43 2025 +0000 net: openvswitch: Fix the dead loop of MPLS parse [ Upstream commit 0bdc924bfb319fb10d1113cbf091fc26fb7b1f99 ] The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally. stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '__be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 Fixes: fbdcdd78da7c ("Change in Openvswitch to support MPLS label depth of 3 in ingress direction") Signed-off-by: Faicker Mo Acked-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/259D3404-575D-4A6D-B263-1DF59A67CF89@zenlayer.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 26ce90f1ce60b0ff587de8d6aec399aa55cab28e Author: Kuniyuki Iwashima Date: Thu May 22 15:18:56 2025 -0700 calipso: Don't call calipso functions for AF_INET sk. [ Upstream commit 6e9f2df1c550ead7cecb3e450af1105735020c92 ] syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the address family matches the socket. The syzkaller must have called connect() for an IPv6 address on an IPv4 socket. We have a proper validation in tcp_v[46]_connect(), but security_socket_connect() is called in the earlier stage. Let's copy the validation to netlbl_conn_setattr(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:txopt_get include/net/ipv6.h:390 [inline] RIP: 0010: Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00 RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070 RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00 R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80 FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f901b61a12d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in: Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.") Reported-by: syzkaller Reported-by: John Cheung Closes: https://lore.kernel.org/netdev/CAP=Rh=M1LzunrcQB1fSGauMrJrhL6GGps5cPAKzHJXj6GQV+-g@mail.gmail.com/ Signed-off-by: Kuniyuki Iwashima Acked-by: Paul Moore Link: https://patch.msgid.link/20250522221858.91240-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7d589b470f39a3db6ff4247d13aa4bb633f36edd Author: Thangaraj Samynathan Date: Mon May 26 11:00:47 2025 +0530 net: lan743x: rename lan743x_reset_phy to lan743x_hw_reset_phy [ Upstream commit 68927eb52d0af04863584930db06075d2610e194 ] rename the function to lan743x_hw_reset_phy to better describe it operation. Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver") Signed-off-by: Thangaraj Samynathan Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250526053048.287095-2-thangaraj.s@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66 Author: KaFai Wan Date: Mon May 26 21:33:58 2025 +0800 bpf: Avoid __bpf_prog_ret0_warn when jit fails [ Upstream commit 86bc9c742426a16b52a10ef61f5b721aecca2344 ] syzkaller reported an issue: WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Modules linked in: CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ... When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable. This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog, but jit failed due to FAULT_INJECTION. As a result, incorrectly treats the program as valid, when the program runs it calls `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1). Reported-by: syzbot+0903f6d7f285e41cdf10@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/6816e34e.a70a0220.254cdc.002c.GAE@google.com Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to enable jits") Signed-off-by: KaFai Wan Link: https://lore.kernel.org/r/20250526133358.2594176-1-mannkafai@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f398d2dfe450ce2c031d10b585448862d74a0501 Author: Nikita Zhandarovich Date: Tue May 20 14:32:39 2025 +0300 net: usb: aqc111: fix error handling of usbnet read calls [ Upstream commit 405b0d610745fb5e84fc2961d9b960abb9f3d107 ] Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 ("net: asix: add proper error handling of usb read errors"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 Reported-by: syzbot+3b6b9ff7b80430020c7b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3b6b9ff7b80430020c7b Tested-by: syzbot+3b6b9ff7b80430020c7b@syzkaller.appspotmail.com Fixes: df2d59a2ab6c ("net: usb: aqc111: Add support for getting and setting of MAC address") Signed-off-by: Nikita Zhandarovich Link: https://patch.msgid.link/20250520113240.2369438-1-n.zhandarovich@fintech.ru Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 42a44e25eee4efe73d36308626d7ac1703cc0b98 Author: Fernando Fernandez Mancera Date: Wed May 21 11:41:08 2025 +0200 netfilter: nft_tunnel: fix geneve_opt dump [ Upstream commit 22a9613de4c29d7d0770bfb8a5a9d73eb8df7dad ] When dumping a nft_tunnel with more than one geneve_opt configured the netlink attribute hierarchy should be as follow: NFTA_TUNNEL_KEY_OPTS | |--NFTA_TUNNEL_KEY_OPTS_GENEVE | | | |--NFTA_TUNNEL_KEY_GENEVE_CLASS | |--NFTA_TUNNEL_KEY_GENEVE_TYPE | |--NFTA_TUNNEL_KEY_GENEVE_DATA | |--NFTA_TUNNEL_KEY_OPTS_GENEVE | | | |--NFTA_TUNNEL_KEY_GENEVE_CLASS | |--NFTA_TUNNEL_KEY_GENEVE_TYPE | |--NFTA_TUNNEL_KEY_GENEVE_DATA | |--NFTA_TUNNEL_KEY_OPTS_GENEVE ... Otherwise, userspace tools won't be able to fetch the geneve options configured correctly. Fixes: 925d844696d9 ("netfilter: nft_tunnel: add support for geneve opts") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4edb40b05cb6a261775abfd8046804ca139a5546 Author: Jiayuan Chen Date: Fri May 16 22:17:12 2025 +0800 bpf, sockmap: Avoid using sk_socket after free when sending [ Upstream commit 8259eb0e06d8f64c700f5fbdb28a5c18e10de291 ] The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... ''' Fixes: 4b4647add7d3 ("sock_map: avoid race between sock_map_close and sk_psock_put") Reported-by: Michal Luczaj Signed-off-by: Jiayuan Chen Signed-off-by: Martin KaFai Lau Reviewed-by: John Fastabend Link: https://lore.kernel.org/r/20250516141713.291150-1-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin commit d796723b14813a6f8833eaa35df6f5af92128eec Author: Li RongQing Date: Wed May 21 11:46:47 2025 +0800 vfio/type1: Fix error unwind in migration dirty bitmap allocation [ Upstream commit 4518e5a60c7fbf0cdff393c2681db39d77b4f87e ] When setting up dirty page tracking at the vfio IOMMU backend for device migration, if an error is encountered allocating a tracking bitmap, the unwind loop fails to free previously allocated tracking bitmaps. This occurs because the wrong loop index is used to generate the tracking object. This results in unintended memory usage for the life of the current DMA mappings where bitmaps were successfully allocated. Use the correct loop index to derive the tracking object for freeing during unwind. Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking") Signed-off-by: Li RongQing Link: https://lore.kernel.org/r/20250521034647.2877-1-lirongqing@baidu.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 83c1ed5c83ca59affeadefe8c912837e5adc45b3 Author: Florian Westphal Date: Wed May 21 11:38:47 2025 +0200 netfilter: nf_tables: nft_fib_ipv6: fix VRF ipv4/ipv6 result discrepancy [ Upstream commit 8b53f46eb430fe5b42d485873b85331d2de2c469 ] With a VRF, ipv4 and ipv6 FIB expression behave differently. fib daddr . iif oif Will return the input interface name for ipv4, but the real device for ipv6. Example: If VRF device name is tvrf and real (incoming) device is veth0. First round is ok, both ipv4 and ipv6 will yield 'veth0'. But in the second round (incoming device will be set to "tvrf"), ipv4 will yield "tvrf" whereas ipv6 returns "veth0" for the second round too. This makes ipv6 behave like ipv4. A followup patch will add a test case for this, without this change it will fail with: get element inet t fibif6iif { tvrf . dead:1::99 . tvrf } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FAIL: did not find tvrf . dead:1::99 . tvrf in fibif6iif Alternatively we could either not do anything at all or change ipv4 to also return the lower/real device, however, nft (userspace) doc says "iif: if fib lookup provides a route then check its output interface is identical to the packets input interface." which is what the nft fib ipv4 behaviour is. Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7ee3fb6258da8c890a51b514f60d7570dc703605 Author: Toke Høiland-Jørgensen Date: Wed Apr 2 13:22:16 2025 +0200 wifi: ath9k_htc: Abort software beacon handling if disabled [ Upstream commit ac4e317a95a1092b5da5b9918b7118759342641c ] A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled. Reported-by: Robert Morris Closes: https://lore.kernel.org/r/88967.1743099372@localhost Fixes: 832f6a18fc2a ("ath9k_htc: Add beacon slots") Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250402112217.58533-1-toke@toke.dk Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1ee8ea6937d13b20f90ff35d71ccc03ba448182d Author: Alexey Kodanev Date: Tue May 13 12:13:04 2025 +0000 wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds [ Upstream commit 4c2c372de2e108319236203cce6de44d70ae15cd ] Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. Fixes: 4136214f7c46 ("rtw88: add BT co-existence support") Signed-off-by: Alexey Kodanev Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com Signed-off-by: Sasha Levin commit 7f9efa13f2af6516f609257863fe38746ecb502c Author: Ilya Leoshkevich Date: Mon May 12 14:26:15 2025 +0200 s390/bpf: Store backchain even for leaf progs [ Upstream commit 5f55f2168432298f5a55294831ab6a76a10cb3c3 ] Currently a crash in a leaf prog (caused by a bug) produces the following call trace: [<000003ff600ebf00>] bpf_prog_6df0139e1fbf2789_fentry+0x20/0x78 [<0000000000000000>] 0x0 This is because leaf progs do not store backchain. Fix by making all progs do it. This is what GCC and Clang-generated code does as well. Now the call trace looks like this: [<000003ff600eb0f2>] bpf_prog_6df0139e1fbf2789_fentry+0x2a/0x80 [<000003ff600ed096>] bpf_trampoline_201863462940+0x96/0xf4 [<000003ff600e3a40>] bpf_prog_05f379658fdd72f2_classifier_0+0x58/0xc0 [<000003ffe0aef070>] bpf_test_run+0x210/0x390 [<000003ffe0af0dc2>] bpf_prog_test_run_skb+0x25a/0x668 [<000003ffe038a90e>] __sys_bpf+0xa46/0xdb0 [<000003ffe038ad0c>] __s390x_sys_bpf+0x44/0x50 [<000003ffe0defea8>] __do_syscall+0x150/0x280 [<000003ffe0e01d5c>] system_call+0x74/0x98 Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by: Ilya Leoshkevich Link: https://lore.kernel.org/r/20250512122717.54878-1-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2b901bf2fa230b48cc876d7d34586eaa378d22f2 Author: Vincent Knecht Date: Mon Apr 14 18:45:12 2025 +0200 clk: qcom: gcc-msm8939: Fix mclk0 & mclk1 for 24 MHz [ Upstream commit 9e7acf70cf6aa7b22f67d911f50a8cd510e8fb00 ] Fix mclk0 & mclk1 parent map to use correct GPLL6 configuration and freq_tbl to use GPLL6 instead of GPLL0 so that they tick at 24 MHz. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Suggested-by: Stephan Gerhold Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Signed-off-by: Vincent Knecht Link: https://lore.kernel.org/r/20250414-gcc-msm8939-fixes-mclk-v2-resend2-v2-1-5ddcf572a6de@mailoo.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ee90be48edb3dac612e0b7f5332482a9e8be2696 Author: Tao Chen Date: Tue May 13 12:27:47 2025 +0800 bpf: Fix WARN() in get_bpf_raw_tp_regs [ Upstream commit 3880cdbed1c4607e378f58fa924c5d6df900d1d3 ] syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first. Fixes: 9594dc3c7e71 ("bpf: fix nested bpf tracepoints with per-cpu data") Reported-by: syzbot+45b0c89a0fc7ae8dbadc@syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250513042747.757042-1-chen.dylane@linux.dev Closes: https://lore.kernel.org/bpf/8bc2554d-1052-4922-8832-e0078a033e1d@gmail.com Signed-off-by: Sasha Levin commit 2ecafe59668d2506a68459a9d169ebe41a147a41 Author: Andy Shevchenko Date: Thu May 8 23:08:07 2025 +0300 pinctrl: at91: Fix possible out-of-boundary access [ Upstream commit 762ef7d1e6eefad9896560bfcb9bcf7f1b6df9c1 ] at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks. Fixes: 6732ae5cb47c ("ARM: at91: add pinctrl support") Signed-off-by: Andy Shevchenko Closes: https://lore.kernel.org/r/202505052343.UHF1Zo93-lkp@intel.com/ Link: https://lore.kernel.org/20250508200807.1384558-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 12cda7fcc4cfd6f9ada27a01105f9b9638c4406d Author: Anton Protopopov Date: Sat May 10 18:20:11 2025 +0000 libbpf: Use proper errno value in nlattr [ Upstream commit fd5fd538a1f4b34cee6823ba0ddda2f7a55aca96 ] Return value of the validate_nla() function can be propagated all the way up to users of libbpf API. In case of error this libbpf version of validate_nla returns -1 which will be seen as -EPERM from user's point of view. Instead, return a more reasonable -EINVAL. Fixes: bbf48c18ee0c ("libbpf: add error reporting in XDP") Suggested-by: Andrii Nakryiko Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250510182011.2246631-1-a.s.protopopov@gmail.com Signed-off-by: Sasha Levin commit 2fef0e86682fa39ec48cbb120fdc13ff96857792 Author: Jiayuan Chen Date: Fri Apr 25 13:59:57 2025 +0800 ktls, sockmap: Fix missing uncharge operation [ Upstream commit 79f0c39ae7d3dc628c01b02f23ca5d01f9875040 ] When we specify apply_bytes, we divide the msg into multiple segments, each with a length of 'send', and every time we send this part of the data using tcp_bpf_sendmsg_redir(), we use sk_msg_return_zero() to uncharge the memory of the specified 'send' size. However, if the first segment of data fails to send, for example, the peer's buffer is full, we need to release all of the msg. When releasing the msg, we haven't uncharged the memory of the subsequent segments. This modification does not make significant logical changes, but only fills in the missing uncharge places. This issue has existed all along, until it was exposed after we added the apply test in test_sockmap: commit 3448ad23b34e ("selftests/bpf: Add apply_bytes test to test_txmsg_redir_wait_sndmem in test_sockmap") Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Reported-by: Cong Wang Closes: https://lore.kernel.org/bpf/aAmIi0vlycHtbXeb@pop-os.localdomain/T/#t Signed-off-by: Jiayuan Chen Signed-off-by: Martin KaFai Lau Acked-by: John Fastabend Reviewed-by: Cong Wang Link: https://lore.kernel.org/r/20250425060015.6968-2-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin commit 54ce9bcdaee59d4ef0703f390d55708557818f9e Author: Henry Martin Date: Wed Apr 2 10:05:13 2025 +0800 clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() [ Upstream commit 73c46d9a93d071ca69858dea3f569111b03e549e ] devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Signed-off-by: Henry Martin Reviewed-by: Dave Stevenson Link: https://lore.kernel.org/r/20250402020513.42628-1-bsdhenrymartin@gmail.com Reviewed-by: Stefan Wahren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c22099a648809c818260978e3a10ccdb639e01c7 Author: Luca Weiss Date: Fri Apr 25 14:12:57 2025 +0200 clk: qcom: gcc-sm6350: Add *_wait_val values for GDSCs [ Upstream commit afdfd829a99e467869e3ca1955fb6c6e337c340a ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-3-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9c5268e5d6334057bd0efdc9e8d7c6ca7143ae81 Author: Anton Protopopov Date: Fri May 2 19:30:31 2025 +0000 bpf: Fix uninitialized values in BPF_{CORE,PROBE}_READ [ Upstream commit 41d4ce6df3f4945341ec509a840cc002a413b6cc ] With the latest LLVM bpf selftests build will fail with the following error message: progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe] 710 | proc_exec_data->parent_uid = BPF_CORE_READ(parent_task, real_cred, uid.val); | ^ tools/testing/selftests/bpf/tools/include/bpf/bpf_core_read.h:520:35: note: expanded from macro 'BPF_CORE_READ' 520 | ___type((src), a, ##__VA_ARGS__) __r; \ | ^ This happens because BPF_CORE_READ (and other macro) declare the variable __r using the ___type macro which can inherit const modifier from intermediate types. Fix this by using __typeof_unqual__, when supported. (And when it is not supported, the problem shouldn't appear, as older compilers haven't complained.) Fixes: 792001f4f7aa ("libbpf: Add user-space variants of BPF_CORE_READ() family of macros") Fixes: a4b09a9ef945 ("libbpf: Add non-CO-RE variants of BPF_CORE_READ() macro family") Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250502193031.3522715-1-a.s.protopopov@gmail.com Signed-off-by: Sasha Levin commit f9784da76ad7be66230e829e743bdf68a2c49e56 Author: Patrisious Haddad Date: Mon Apr 28 14:34:07 2025 +0300 RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction [ Upstream commit 5d2ea5aebbb2f3ebde4403f9c55b2b057e5dd2d6 ] Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8 Fixes: e2013b212f9f ("net/mlx5_core: Add RQ and SQ event handling") Signed-off-by: Patrisious Haddad Link: https://patch.msgid.link/3181433ccdd695c63560eeeb3f0c990961732101.1745839855.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e9022196bdbe556c721152f35e6d9b253c69596b Author: Zhongqiu Duan Date: Thu Apr 17 15:49:30 2025 +0000 netfilter: nft_quota: match correctly when the quota just depleted [ Upstream commit bfe7cfb65c753952735c3eed703eba9a8b96a18d ] The xt_quota compares skb length with remaining quota, but the nft_quota compares it with consumed bytes. The xt_quota can match consumed bytes up to quota at maximum. But the nft_quota break match when consumed bytes equal to quota. i.e., nft_quota match consumed bytes in [0, quota - 1], not [0, quota]. Fixes: 795595f68d6c ("netfilter: nft_quota: dump consumed quota") Signed-off-by: Zhongqiu Duan Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ba18b0b9272f5e2fc9ebe408e594c4a39527821a Author: Huajian Yang Date: Thu Apr 17 17:29:53 2025 +0800 netfilter: bridge: Move specific fragmented packet to slow_path instead of dropping it [ Upstream commit aa04c6f45b9224b949aa35d4fa5f8d0ba07b23d4 ] The config NF_CONNTRACK_BRIDGE will change the bridge forwarding for fragmented packets. The original bridge does not know that it is a fragmented packet and forwards it directly, after NF_CONNTRACK_BRIDGE is enabled, function nf_br_ip_fragment and br_ip6_fragment will check the headroom. In original br_forward, insufficient headroom of skb may indeed exist, but there's still a way to save the skb in the device driver after dev_queue_xmit.So droping the skb will change the original bridge forwarding in some cases. Fixes: 3c171f496ef5 ("netfilter: bridge: add connection tracking system") Signed-off-by: Huajian Yang Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c6c7e7ab962b1f9f35b7efb159533409a3272008 Author: Anton Protopopov Date: Wed Apr 30 12:08:20 2025 +0000 libbpf: Use proper errno value in linker [ Upstream commit 358b1c0f56ebb6996fcec7dcdcf6bae5dcbc8b6c ] Return values of the linker_append_sec_data() and the linker_append_elf_relos() functions are propagated all the way up to users of libbpf API. In some error cases these functions return -1 which will be seen as -EPERM from user's point of view. Instead, return a more reasonable -EINVAL. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250430120820.2262053-1-a.s.protopopov@gmail.com Signed-off-by: Sasha Levin commit a6412e93cf4adb8447c11f6ab53c03e12adf1d9a Author: Chao Yu Date: Mon Apr 14 18:52:37 2025 +0800 f2fs: fix to detect gcing page in f2fs_is_cp_guaranteed() [ Upstream commit aa1be8dd64163eca4dde7fd2557eb19927a06a47 ] Jan Prusakowski reported a f2fs bug as below: f2fs/007 will hang kernel during testing w/ below configs: kernel 6.12.18 (from pixel-kernel/android16-6.12) export MKFS_OPTIONS="-O encrypt -O extra_attr -O project_quota -O quota" export F2FS_MOUNT_OPTIONS="test_dummy_encryption,discard,fsync_mode=nobarrier,reserve_root=32768,checkpoint_merge,atgc" cat /proc//stack f2fs_wait_on_all_pages+0xa3/0x130 do_checkpoint+0x40c/0x5d0 f2fs_write_checkpoint+0x258/0x550 kill_f2fs_super+0x14f/0x190 deactivate_locked_super+0x30/0xb0 cleanup_mnt+0xba/0x150 task_work_run+0x59/0xa0 syscall_exit_to_user_mode+0x12d/0x130 do_syscall_64+0x57/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e cat /sys/kernel/debug/f2fs/status - IO_W (CP: -256, Data: 256, Flush: ( 0 0 1), Discard: ( 0 0)) cmd: 0 undiscard: 0 CP IOs reference count becomes negative. The root cause is: After 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration"), we will tag page w/ gcing flag for raw page of cluster during its migration. However, if the inode is both encrypted and compressed, during ioc_decompress(), it will tag page w/ gcing flag, and it increase F2FS_WB_DATA reference count: - f2fs_write_multi_page - f2fs_write_raw_page - f2fs_write_single_page - do_write_page - f2fs_submit_page_write - WB_DATA_TYPE(bio_page, fio->compressed_page) : bio_page is encrypted, so mapping is NULL, and fio->compressed_page is NULL, it returns F2FS_WB_DATA - inc_page_count(.., F2FS_WB_DATA) Then, during end_io(), it decrease F2FS_WB_CP_DATA reference count: - f2fs_write_end_io - f2fs_compress_write_end_io - fscrypt_pagecache_folio : get raw page from encrypted page - WB_DATA_TYPE(&folio->page, false) : raw page has gcing flag, it returns F2FS_WB_CP_DATA - dec_page_count(.., F2FS_WB_CP_DATA) In order to fix this issue, we need to detect gcing flag in raw page in f2fs_is_cp_guaranteed(). Fixes: 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration") Reported-by: Jan Prusakowski Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ce6849b76dad52ac55998f2dfa821b0d53da6a0c Author: Chao Yu Date: Mon Apr 14 18:52:36 2025 +0800 f2fs: clean up w/ fscrypt_is_bounce_page() [ Upstream commit 0c708e35cf26449ca317fcbfc274704660b6d269 ] Just cleanup, no logic changes. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 65b935d4e5c449bc55abbd75de1a4450988928f9 Author: Jason Gunthorpe Date: Fri Apr 25 10:08:37 2025 -0300 iommu: Protect against overflow in iommu_pgsize() [ Upstream commit e586e22974d2b7acbef3c6c3e01b2d5ce69efe33 ] On a 32 bit system calling: iommu_map(0, 0x40000000) When using the AMD V1 page table type with a domain->pgsize of 0xfffff000 causes iommu_pgsize() to miscalculate a result of: size=0x40000000 count=2 count should be 1. This completely corrupts the mapping process. This is because the final test to adjust the pagesize malfunctions when the addition overflows. Use check_add_overflow() to prevent this. Fixes: b1d99dc5f983 ("iommu: Hook up '->unmap_pages' driver callback") Signed-off-by: Jason Gunthorpe Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/0-v1-3ad28fc2e3a3+163327-iommu_overflow_pgsize_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 5c3e52ab78878601eada0587302a3a2597617cc2 Author: Junxian Huang Date: Mon Apr 21 21:27:49 2025 +0800 RDMA/hns: Include hnae3.h in hns_roce_hw_v2.h [ Upstream commit 2b11d33de23262cb20d1dcb24b586dbb8f54d463 ] hns_roce_hw_v2.h has a direct dependency on hnae3.h due to the inline function hns_roce_write64(), but it doesn't include this header currently. This leads to that files including hns_roce_hw_v2.h must also include hnae3.h to avoid compilation errors, even if they themselves don't really rely on hnae3.h. This doesn't make sense, hns_roce_hw_v2.h should include hnae3.h directly. Fixes: d3743fa94ccd ("RDMA/hns: Fix the chip hanging caused by sending doorbell during reset") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20250421132750.1363348-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f1ba4e35fb3f40e26ca3daabf8d9ce0e4f5506bc Author: Dmitry Antipov Date: Tue Apr 15 12:07:20 2025 +0300 wifi: rtw88: do not ignore hardware read error during DPK [ Upstream commit 20d3c19bd8f9b498173c198eadf54580c8caa336 ] In 'rtw8822c_dpk_cal_coef1()', do not ignore error returned by 'check_hw_ready()' but issue a warning to denote possible DPK issue. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support") Suggested-by: Ping-Ke Shih Signed-off-by: Dmitry Antipov Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250415090720.194048-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin commit 6dfe62db59f30522beb2889b4c816bde425a0de4 Author: Viktor Malik Date: Tue Apr 15 17:50:14 2025 +0200 libbpf: Fix buffer overflow in bpf_object__init_prog [ Upstream commit ee684de5c1b0ac01821320826baec7da93f3615b ] As shown in [1], it is possible to corrupt a BPF ELF file such that arbitrary BPF instructions are loaded by libbpf. This can be done by setting a symbol (BPF program) section offset to a large (unsigned) number such that
overflows and points before the section data in the memory. Consider the situation below where: - prog_start = sec_start + symbol_offset <-- size_t overflow here - prog_end = prog_start + prog_size prog_start sec_start prog_end sec_end | | | | v v v v .....................|################################|............ The report in [1] also provides a corrupted BPF ELF which can be used as a reproducer: $ readelf -S crash Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align ... [ 2] uretprobe.mu[...] PROGBITS 0000000000000000 00000040 0000000000000068 0000000000000000 AX 0 0 8 $ readelf -s crash Symbol table '.symtab' contains 8 entries: Num: Value Size Type Bind Vis Ndx Name ... 6: ffffffffffffffb8 104 FUNC GLOBAL DEFAULT 2 handle_tp Here, the handle_tp prog has section offset ffffffffffffffb8, i.e. will point before the actual memory where section 2 is allocated. This is also reported by AddressSanitizer: ================================================================= ==1232==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c7302fe0000 at pc 0x7fc3046e4b77 bp 0x7ffe64677cd0 sp 0x7ffe64677490 READ of size 104 at 0x7c7302fe0000 thread T0 #0 0x7fc3046e4b76 in memcpy (/lib64/libasan.so.8+0xe4b76) #1 0x00000040df3e in bpf_object__init_prog /src/libbpf/src/libbpf.c:856 #2 0x00000040df3e in bpf_object__add_programs /src/libbpf/src/libbpf.c:928 #3 0x00000040df3e in bpf_object__elf_collect /src/libbpf/src/libbpf.c:3930 #4 0x00000040df3e in bpf_object_open /src/libbpf/src/libbpf.c:8067 #5 0x00000040f176 in bpf_object__open_file /src/libbpf/src/libbpf.c:8090 #6 0x000000400c16 in main /poc/poc.c:8 #7 0x7fc3043d25b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) #8 0x7fc3043d2667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) #9 0x000000400b34 in _start (/poc/poc+0x400b34) 0x7c7302fe0000 is located 64 bytes before 104-byte region [0x7c7302fe0040,0x7c7302fe00a8) allocated by thread T0 here: #0 0x7fc3046e716b in malloc (/lib64/libasan.so.8+0xe716b) #1 0x7fc3045ee600 in __libelf_set_rawdata_wrlock (/lib64/libelf.so.1+0xb600) #2 0x7fc3045ef018 in __elf_getdata_rdlock (/lib64/libelf.so.1+0xc018) #3 0x00000040642f in elf_sec_data /src/libbpf/src/libbpf.c:3740 The problem here is that currently, libbpf only checks that the program end is within the section bounds. There used to be a check `while (sec_off < sec_sz)` in bpf_object__add_programs, however, it was removed by commit 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions"). Add a check for detecting the overflow of `sec_off + prog_sz` to bpf_object__init_prog to fix this issue. [1] https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") Reported-by: lmarch2 <2524158037@qq.com> Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Reviewed-by: Shung-Hsi Yu Link: https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Link: https://lore.kernel.org/bpf/20250415155014.397603-1-vmalik@redhat.com Signed-off-by: Sasha Levin commit f4b0ce074bd68d1f5554b514ed4598ea1ec0bc4b Author: Hari Kalavakunta Date: Wed Apr 9 18:23:08 2025 -0700 net: ncsi: Fix GCPS 64-bit member variables [ Upstream commit e8a1bd8344054ce27bebf59f48e3f6bc10bc419b ] Correct Get Controller Packet Statistics (GCPS) 64-bit wide member variables, as per DSP0222 v1.0.0 and forward specs. The Driver currently collects these stats, but they are yet to be exposed to the user. Therefore, no user impact. Statistics fixes: Total Bytes Received (byte range 28..35) Total Bytes Transmitted (byte range 36..43) Total Unicast Packets Received (byte range 44..51) Total Multicast Packets Received (byte range 52..59) Total Broadcast Packets Received (byte range 60..67) Total Unicast Packets Transmitted (byte range 68..75) Total Multicast Packets Transmitted (byte range 76..83) Total Broadcast Packets Transmitted (byte range 84..91) Valid Bytes Received (byte range 204..11) Signed-off-by: Hari Kalavakunta Reviewed-by: Paul Fertser Link: https://patch.msgid.link/20250410012309.1343-1-kalavakunta.hari.prasad@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d Author: Chao Yu Date: Tue Apr 8 20:22:08 2025 +0800 f2fs: fix to do sanity check on sbi->total_valid_block_count [ Upstream commit 05872a167c2cab80ef186ef23cc34a6776a1a30c ] syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag. Fixes: 39a53e0ce0df ("f2fs: add superblock and major in-memory structure") Reported-by: syzbot+8b376a77b2f364097fbe@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/67f3c0b2.050a0220.396535.0547.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit d6181bd1dfa1a327096e2edc5f4d9bd582bbf012 Author: Jiayuan Chen Date: Mon Apr 7 22:21:21 2025 +0800 bpf, sockmap: fix duplicated data transmission [ Upstream commit 3b4f14b794287be137ea2c6158765d1ea1e018a4 ] In the !ingress path under sk_psock_handle_skb(), when sending data to the remote under snd_buf limitations, partial skb data might be transmitted. Although we preserved the partial transmission state (offset/length), the state wasn't properly consumed during retries. This caused the retry path to resend the entire skb data instead of continuing from the previous offset, resulting in data overlap at the receiver side. Fixes: 405df89dd52c ("bpf, sockmap: Improved check for empty queue") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250407142234.47591-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2160dcc38acfbf4b36500388fd3bb5251eb994d0 Author: Jacob Moroni Date: Thu Feb 20 17:56:12 2025 +0000 IB/cm: use rwlock for MAD agent lock [ Upstream commit 4dab26bed543584577b64b36aadb8b5b165bf44f ] In workloads where there are many processes establishing connections using RDMA CM in parallel (large scale MPI), there can be heavy contention for mad_agent_lock in cm_alloc_msg. This contention can occur while inside of a spin_lock_irq region, leading to interrupts being disabled for extended durations on many cores. Furthermore, it leads to the serialization of rdma_create_ah calls, which has negative performance impacts for NICs which are capable of processing multiple address handle creations in parallel. The end result is the machine becoming unresponsive, hung task warnings, netdev TX timeouts, etc. Since the lock appears to be only for protection from cm_remove_one, it can be changed to a rwlock to resolve these issues. Reproducer: Server: for i in $(seq 1 512); do ucmatose -c 32 -p $((i + 5000)) & done Client: for i in $(seq 1 512); do ucmatose -c 32 -p $((i + 5000)) -s 10.2.0.52 & done Fixes: 76039ac9095f ("IB/cm: Protect cm_dev, cm_ports and mad_agent with kref and lock") Link: https://patch.msgid.link/r/20250220175612.2763122-1-jmoroni@google.com Signed-off-by: Jacob Moroni Acked-by: Eric Dumazet Reviewed-by: Zhu Yanjun Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f9507cf2dd0e1ed5028c0e8240da6fe5fd3110d3 Author: Stone Zhang Date: Thu Mar 20 13:31:45 2025 +0800 wifi: ath11k: fix node corruption in ar->arvifs list [ Upstream commit 31e98e277ae47f56632e4d663b1d4fd12ba33ea8 ] In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Stone Zhang Link: https://patch.msgid.link/20250320053145.3445187-1-quic_stonez@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e74b9a7269aa9d7736259bbc19aaa0f73813f833 Author: Huang Yiwei Date: Wed May 7 12:57:57 2025 +0800 firmware: SDEI: Allow sdei initialization without ACPI_APEI_GHES [ Upstream commit 59529bbe642de4eb2191a541d9b4bae7eb73862e ] SDEI usually initialize with the ACPI table, but on platforms where ACPI is not used, the SDEI feature can still be used to handle specific firmware calls or other customized purposes. Therefore, it is not necessary for ARM_SDE_INTERFACE to depend on ACPI_APEI_GHES. In commit dc4e8c07e9e2 ("ACPI: APEI: explicit init of HEST and GHES in acpi_init()"), to make APEI ready earlier, sdei_init was moved into acpi_ghes_init instead of being a standalone initcall, adding ACPI_APEI_GHES dependency to ARM_SDE_INTERFACE. This restricts the flexibility and usability of SDEI. This patch corrects the dependency in Kconfig and splits sdei_init() into two separate functions: sdei_init() and acpi_sdei_init(). sdei_init() will be called by arch_initcall and will only initialize the platform driver, while acpi_sdei_init() will initialize the device from acpi_ghes_init() when ACPI is ready. This allows the initialization of SDEI without ACPI_APEI_GHES enabled. Fixes: dc4e8c07e9e2 ("ACPI: APEI: explicit init of HEST and GHES in apci_init()") Cc: Shuai Xue Signed-off-by: Huang Yiwei Reviewed-by: Shuai Xue Reviewed-by: Gavin Shan Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20250507045757.2658795-1-quic_hyiwei@quicinc.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 809b522315a0d8b6815294e3c17effbff163c115 Author: Biju Das Date: Wed Feb 5 11:21:35 2025 +0000 drm/tegra: rgb: Fix the unbound reference count [ Upstream commit 3c3642335065c3bde0742b0edc505b6ea8fdc2b3 ] The of_get_child_by_name() increments the refcount in tegra_dc_rgb_probe, but the driver does not decrement the refcount during unbind. Fix the unbound reference count using devm_add_action_or_reset() helper. Fixes: d8f4a9eda006 ("drm: Add NVIDIA Tegra20 support") Signed-off-by: Biju Das Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20250205112137.36055-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit afc9153b1e576a5225e2f680774a1afa9bb56fdb Author: Kees Cook Date: Fri Apr 25 23:14:32 2025 -0700 drm/vkms: Adjust vkms_state->active_planes allocation type [ Upstream commit 258aebf100540d36aba910f545d4d5ddf4ecaf0b ] In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct vkms_plane_state **", but the returned type will be "struct drm_plane **". These are the same size (pointer size), but the types don't match. Adjust the allocation type to match the assignment. Signed-off-by: Kees Cook Reviewed-by: Louis Chauvet Fixes: 8b1865873651 ("drm/vkms: totally reworked crc data tracking") Link: https://lore.kernel.org/r/20250426061431.work.304-kees@kernel.org Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin commit 58d0e3088812bcc41010499969e6e3f3d7bfd80d Author: Biju Das Date: Thu Nov 16 12:24:24 2023 +0000 drm: rcar-du: Fix memory leak in rcar_du_vsps_init() [ Upstream commit 91e3bf09a90bb4340c0c3c51396e7531555efda4 ] The rcar_du_vsps_init() doesn't free the np allocated by of_parse_phandle_with_fixed_args() for the non-error case. Fix memory leak for the non-error case. While at it, replace the label 'error'->'done' as it applies to non-error case as well and update the error check condition for rcar_du_vsp_init() to avoid breakage in future, if it returns positive value. Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP") Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20231116122424.80136-1-biju.das.jz@bp.renesas.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 39044a10d912b7d075b7951e9b6dab7578f6cd12 Author: Neill Kapron Date: Sun Apr 27 09:40:58 2025 +0000 selftests/seccomp: fix syscall_restart test for arm compat [ Upstream commit 797002deed03491215a352ace891749b39741b69 ] The inconsistencies in the systcall ABI between arm and arm-compat can can cause a failure in the syscall_restart test due to the logic attempting to work around the differences. The 'machine' field for an ARM64 device running in compat mode can report 'armv8l' or 'armv8b' which matches with the string 'arm' when only examining the first three characters of the string. This change adds additional validation to the workaround logic to make sure we only take the arm path when running natively, not in arm-compat. Fixes: 256d0afb11d6 ("selftests/seccomp: build and pass on arm64") Signed-off-by: Neill Kapron Link: https://lore.kernel.org/r/20250427094103.3488304-2-nkapron@google.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 7287af1ec4d3bbfadc129bac97011e76945dfa76 Author: Miaoqian Lin Date: Tue Mar 18 23:17:12 2025 +0800 firmware: psci: Fix refcount leak in psci_dt_init [ Upstream commit 7ff37d29fd5c27617b9767e1b8946d115cf93a1e ] Fix a reference counter leak in psci_dt_init() where of_node_put(np) was missing after of_find_matching_node_and_match() when np is unavailable. Fixes: d09a0011ec0d ("drivers: psci: Allow PSCI node to be disabled") Signed-off-by: Miaoqian Lin Reviewed-by: Gavin Shan Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20250318151712.28763-1-linmq006@gmail.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1b6780143d59f19cff9dae290824af3393fcb0d5 Author: Finn Thain Date: Thu Apr 24 10:07:26 2025 +1000 m68k: mac: Fix macintosh_config for Mac II [ Upstream commit 52ae3f5da7e5adbe3d1319573b55dac470abb83c ] When booted on my Mac II, the kernel prints this: Detected Macintosh model: 6 Apple Macintosh Unknown The catch-all entry ("Unknown") is mac_data_table[0] which is only needed in the unlikely event that the bootinfo model ID can't be matched. When model ID is 6, the search should begin and end at mac_data_table[1]. Fix the off-by-one error that causes this problem. Cc: Joshua Thompson Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/d0f30a551064ca4810b1c48d5a90954be80634a9.1745453246.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 5390b3d4c6d41d05bb9149d094d504cbc9ea85bf Author: Andrey Vatoropin Date: Tue Mar 18 13:42:18 2025 +0000 fs/ntfs3: handle hdr_first_de() return value [ Upstream commit af5cab0e5b6f8edb0be51a9f47f3f620e0b4fd70 ] The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Andrey Vatoropin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 892a242ca5b1f2530388d568998a685fae90b625 Author: Jonas Karlman Date: Tue Feb 25 10:40:33 2025 +0100 media: rkvdec: Fix frame size enumeration [ Upstream commit f270005b99fa19fee9a6b4006e8dee37c10f1944 ] The VIDIOC_ENUM_FRAMESIZES ioctl should return all frame sizes (i.e. width and height in pixels) that the device supports for the given pixel format. It doesn't make a lot of sense to return the frame-sizes in a stepwise manner, which is used to enforce hardware alignments requirements for CAPTURE buffers, for coded formats. Instead, applications should receive an indication, about the maximum supported frame size for that hardware decoder, via a continuous frame-size enumeration. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Suggested-by: Alex Bee Signed-off-by: Jonas Karlman Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 85cdcb834fb490731ff2d123f87ca799c57dacf2 Author: Charles Han Date: Thu Mar 27 12:04:35 2025 +0800 drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table [ Upstream commit 820116a39f96bdc7d426c33a804b52f53700a919 ] The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced. Fixes: b3892e2bb519 ("drm/amd/pp: Use atombios api directly in powerplay (v2)") Fixes: 5f92b48cf62c ("drm/amd/pm: add mc register table initialization") Signed-off-by: Charles Han Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 259b74c2b3297ee464cd4a88199dd6aad4d9bb8d Author: Geert Uytterhoeven Date: Fri May 16 15:32:06 2025 +0200 spi: sh-msiof: Fix maximum DMA transfer size [ Upstream commit 0941d5166629cb766000530945e54b4e49680c68 ] The maximum amount of data to transfer in a single DMA request is calculated from the FIFO sizes (which is technically not 100% correct, but a simplification, as it is limited by the maximum word count values in the Transmit and Control Data Registers). However, in case there is both data to transmit and to receive, the transmit limit is overwritten by the receive limit. Fix this by using the minimum applicable FIFO size instead. Move the calculation outside the loop, so it is not repeated for each individual DMA transfer. As currently tx_fifo_size is always equal to rx_fifo_size, this bug had no real impact. Fixes: fe78d0b7691c0274 ("spi: sh-msiof: Fix FIFO size to 64 word from 256 word") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/d9961767a97758b2614f2ee8afe1bd56dc900a60.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cfc61c34077ef33e686b059ba9d6efa5694d42c3 Author: Armin Wolf Date: Thu Apr 10 18:54:54 2025 +0200 ACPI: OSI: Stop advertising support for "3.0 _SCP Extensions" [ Upstream commit 8cf4fdac9bdead7bca15fc56fdecdf78d11c3ec6 ] As specified in section 5.7.2 of the ACPI specification the feature group string "3.0 _SCP Extensions" implies that the operating system evaluates the _SCP control method with additional parameters. However the ACPI thermal driver evaluates the _SCP control method without those additional parameters, conflicting with the above feature group string advertised to the firmware thru _OSI. Stop advertising support for this feature string to avoid confusing the ACPI firmware. Fixes: e5f660ebef68 ("ACPI / osi: Collect _OSI handling into one single file") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20250410165456.4173-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 92322500c1aa1b55d3e2ecaffef344977bdc2fcc Author: Jiaqing Zhao Date: Fri May 9 17:06:33 2025 +0000 x86/mtrr: Check if fixed-range MTRRs exist in mtrr_save_fixed_ranges() [ Upstream commit 824c6384e8d9275d4ec7204f3f79a4ac6bc10379 ] When suspending, save_processor_state() calls mtrr_save_fixed_ranges() to save fixed-range MTRRs. On platforms without fixed-range MTRRs like the ACRN hypervisor which has removed fixed-range MTRR emulation, accessing these MSRs will trigger an unchecked MSR access error. Make sure fixed-range MTRRs are supported before access to prevent such error. Since mtrr_state.have_fixed is only set when MTRRs are present and enabled, checking the CPU feature flag in mtrr_save_fixed_ranges() is unnecessary. Fixes: 3ebad5905609 ("[PATCH] x86: Save and restore the fixed-range MTRRs of the BSP when suspending") Signed-off-by: Jiaqing Zhao Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250509170633.3411169-2-jiaqing.zhao@linux.intel.com Signed-off-by: Sasha Levin commit 3319b48d1ba2d60a31d7f034669d5ccf8d6aefbc Author: Zijun Hu Date: Mon May 5 17:26:51 2025 +0800 PM: wakeup: Delete space in the end of string shown by pm_show_wakelocks() [ Upstream commit f0050a3e214aa941b78ad4caf122a735a24d81a6 ] pm_show_wakelocks() is called to generate a string when showing attributes /sys/power/wake_(lock|unlock), but the string ends with an unwanted space that was added back by mistake by commit c9d967b2ce40 ("PM: wakeup: simplify the output logic of pm_show_wakelocks()"). Remove the unwanted space. Fixes: c9d967b2ce40 ("PM: wakeup: simplify the output logic of pm_show_wakelocks()") Signed-off-by: Zijun Hu Link: https://patch.msgid.link/20250505-fix_power-v1-1-0f7f2c2f338c@quicinc.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b227c27359a02caf73506b77149978264df0565d Author: Alexander Shiyan Date: Fri Mar 7 08:38:09 2025 +0300 power: reset: at91-reset: Optimize at91_reset() [ Upstream commit 62d48983f215bf1dd48665913318101fa3414dcf ] This patch adds a small optimization to the low-level at91_reset() function, which includes: - Removes the extra branch, since the following store operations already have proper condition checks. - Removes the definition of the clobber register r4, since it is no longer used in the code. Fixes: fcd0532fac2a ("power: reset: at91-reset: make at91sam9g45_restart() generic") Signed-off-by: Alexander Shiyan Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20250307053809.20245-1-eagle.alexander923@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit bf6a8502a5f4ff6e4d135d795945cdade49ec8b0 Author: Qiuxu Zhuo Date: Thu Apr 17 23:07:18 2025 +0800 EDAC/skx_common: Fix general protection fault [ Upstream commit 20d2d476b3ae18041be423671a8637ed5ffd6958 ] After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur: mce: [Hardware Error]: Machine check events logged Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace: ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common] skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common] skx_mce_check_error+0x17/0x20 [skx_edac_common] ... The issue arose was because the variable 'adxl_component_count' (inside skx_edac_common), which counts the ADXL components, was not reset. During the reloading of i10nm_edac, the count was incremented by the actual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led to an out-of-bounds reference to the ADXL component array, causing the general protection fault above. Fix this issue by resetting the 'adxl_component_count' in adxl_put(), which is called during the unloading of {skx,i10nm}_edac. Fixes: 123b15863550 ("EDAC, i10nm: make skx_common.o a separate module") Reported-by: Feng Xu Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Feng Xu Link: https://lore.kernel.org/r/20250417150724.1170168-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 03657814c828a163be54702084e2be44c29952a0 Author: Ovidiu Panait Date: Fri May 16 15:06:56 2025 +0300 crypto: sun8i-ce - move fallback ahash_request to the end of the struct [ Upstream commit c822831b426307a6ca426621504d3c7f99765a39 ] 'struct ahash_request' has a flexible array at the end, so it must be the last member in a struct, to avoid overwriting other struct members. Therefore, move 'fallback_req' to the end of the 'sun8i_ce_hash_reqctx' struct. Fixes: 56f6d5aee88d ("crypto: sun8i-ce - support hash algorithms") Signed-off-by: Ovidiu Panait Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 02b6619408742e046cb759aee66b8d6652e36ccb Author: Herbert Xu Date: Thu May 15 16:34:04 2025 +0800 crypto: xts - Only add ecb if it is not already there [ Upstream commit 270b6f13454cb7f2f7058c50df64df409c5dcf55 ] Only add ecb to the cipher name if it isn't already ecb. Also use memcmp instead of strncmp since these strings are all stored in an array of length CRYPTO_MAX_ALG_NAME. Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 200b752c00667b3859a99de745afde0a75984447 Author: Herbert Xu Date: Thu May 15 16:28:08 2025 +0800 crypto: lrw - Only add ecb if it is not already there [ Upstream commit 3d73909bddc2ebb3224a8bc2e5ce00e9df70c15d ] Only add ecb to the cipher name if it isn't already ecb. Also use memcmp instead of strncmp since these strings are all stored in an array of length CRYPTO_MAX_ALG_NAME. Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202505151503.d8a6cf10-lkp@intel.com Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9bacddcf6886b54660e05779d8af8a91c0d35250 Author: Herbert Xu Date: Sat May 10 18:43:33 2025 +0800 crypto: marvell/cesa - Avoid empty transfer descriptor [ Upstream commit 1bafd82d9a40cf09c6c40f1c09cc35b7050b1a9f ] The user may set req->src even if req->nbytes == 0. If there is no data to hash from req->src, do not generate an empty TDMA descriptor. Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e1cc69da619588b1488689fe3535a0ba75a2b0e7 Author: Herbert Xu Date: Sat May 10 18:41:31 2025 +0800 crypto: marvell/cesa - Handle zero-length skcipher requests [ Upstream commit 8a4e047c6cc07676f637608a9dd675349b5de0a7 ] Do not access random memory for zero-length skcipher requests. Just return 0. Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's CESA") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c798023fa97373c6b4df1debcf223dcbda6ff531 Author: Ahmed S. Darwish Date: Tue May 6 07:04:13 2025 +0200 x86/cpu: Sanitize CPUID(0x80000000) output [ Upstream commit cc663ba3fe383a628a812f893cc98aafff39ab04 ] CPUID(0x80000000).EAX returns the max extended CPUID leaf available. On x86-32 machines without an extended CPUID range, a CPUID(0x80000000) query will just repeat the output of the last valid standard CPUID leaf on the CPU; i.e., a garbage values. Current tip:x86/cpu code protects against this by doing: eax = cpuid_eax(0x80000000); c->extended_cpuid_level = eax; if ((eax & 0xffff0000) == 0x80000000) { // CPU has an extended CPUID range. Check for 0x80000001 if (eax >= 0x80000001) { cpuid(0x80000001, ...); } } This is correct so far. Afterwards though, the same possibly broken EAX value is used to check the availability of other extended CPUID leaves: if (c->extended_cpuid_level >= 0x80000007) ... if (c->extended_cpuid_level >= 0x80000008) ... if (c->extended_cpuid_level >= 0x8000000a) ... if (c->extended_cpuid_level >= 0x8000001f) ... which is invalid. Fix this by immediately setting the CPU's max extended CPUID leaf to zero if CPUID(0x80000000).EAX doesn't indicate a valid CPUID extended range. While at it, add a comment, similar to kernel/head_32.S, clarifying the CPUID(0x80000000) sanity check. References: 8a50e5135af0 ("x86-32: Use symbolic constants, safer CPUID when enabling EFER.NX") Fixes: 3da99c977637 ("x86: make (early)_identify_cpu more the same between 32bit and 64 bit") Signed-off-by: Ahmed S. Darwish Signed-off-by: Ingo Molnar Cc: Andrew Cooper Cc: H. Peter Anvin Cc: John Ogness Cc: x86-cpuid@lists.linux.dev Link: https://lore.kernel.org/r/20250506050437.10264-3-darwi@linutronix.de Signed-off-by: Sasha Levin commit ada335e8475d9ee0c663df9fc1740f203d821eb1 Author: Corentin Labbe Date: Sun Apr 27 13:12:36 2025 +0200 crypto: sun8i-ss - do not use sg_dma_len before calling DMA functions [ Upstream commit 2dfc7cd74a5e062a5405560447517e7aab1c7341 ] When testing sun8i-ss with multi_v7_defconfig, all CBC algorithm fail crypto selftests. This is strange since on sunxi_defconfig, everything was ok. The problem was in the IV setup loop which never run because sg_dma_len was 0. Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fb2671376bbfa22505caf86b4400ce1cc234156c Author: Qing Wang Date: Sat Apr 5 22:16:35 2025 +0800 perf/core: Fix broken throttling when max_samples_per_tick=1 [ Upstream commit f51972e6f8b9a737b2b3eb588069acb538fa72de ] According to the throttling mechanism, the pmu interrupts number can not exceed the max_samples_per_tick in one tick. But this mechanism is ineffective when max_samples_per_tick=1, because the throttling check is skipped during the first interrupt and only performed when the second interrupt arrives. Perhaps this bug may cause little influence in one tick, but if in a larger time scale, the problem can not be underestimated. When max_samples_per_tick = 1: Allowed-interrupts-per-second max-samples-per-second default-HZ ARCH 200 100 100 X86 500 250 250 ARM64 ... Obviously, the pmu interrupt number far exceed the user's expect. Fixes: e050e3f0a71b ("perf: Fix broken interrupt rate throttling") Signed-off-by: Qing Wang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250405141635.243786-3-wangqing7171@gmail.com Signed-off-by: Sasha Levin commit 333f2d85b6155896fdb21d4285f506ed7d1f043e Author: Andreas Gruenbacher Date: Fri Apr 18 16:40:58 2025 +0200 gfs2: gfs2_create_inode error handling fix [ Upstream commit af4044fd0b77e915736527dd83011e46e6415f01 ] When gfs2_create_inode() finds a directory, make sure to return -EISDIR. Fixes: 571a4b57975a ("GFS2: bugger off early if O_CREAT open finds a directory") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 2f62eda4d974c26bc595425eafd429067541f2c9 Author: Sergey Senozhatsky Date: Fri Mar 28 00:03:50 2025 +0900 thunderbolt: Do not double dequeue a configuration request commit 0f73628e9da1ee39daf5f188190cdbaee5e0c98c upstream. Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set. Signed-off-by: Sergey Senozhatsky Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 2e74fd21b8456020b104dc5819922c252b954cb1 Author: Dave Penkler Date: Wed May 21 14:16:56 2025 +0200 usb: usbtmc: Fix timeout value in get_stb commit 342e4955a1f1ce28c70a589999b76365082dbf10 upstream. wait_event_interruptible_timeout requires a timeout argument in units of jiffies. It was being called in usbtmc_get_stb with the usb timeout value which is in units of milliseconds. Pass the timeout argument converted to jiffies. Fixes: 048c6d88a021 ("usb: usbtmc: Add ioctls to set/get usb timeout") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250521121656.18174-4-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 547f3e6789226fadc6426fdf673f9108151880ef Author: Charles Yeh Date: Wed May 21 21:23:54 2025 +0800 USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB commit d3a889482bd5abf2bbdc1ec3d2d49575aa160c9c upstream. Add new bcd (0x905) to support PL2303GT-2AB (TYPE_HXN). Add new bcd (0x1005) to support PL2303GC-Q20 (TYPE_HXN). Signed-off-by: Charles Yeh Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3f1aac91fc360cb234e3038332e8ea9d506f43c7 Author: Hongyu Xie Date: Mon May 19 10:33:28 2025 +0800 usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device commit a541acceedf4f639f928f41fbb676b75946dc295 upstream. SanDisk 3.2 Gen2 storage device(0781:55e8) doesn't work well with UAS. Log says, [ 6.507865][ 3] [ T159] usb 2-1.4: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd [ 6.540314][ 3] [ T159] usb 2-1.4: New USB device found, idVendor=0781, idProduct=55e8, bcdDevice= 0.01 [ 6.576304][ 3] [ T159] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 6.584727][ 3] [ T159] usb 2-1.4: Product: SanDisk 3.2 Gen2 [ 6.590459][ 3] [ T159] usb 2-1.4: Manufacturer: SanDisk [ 6.595845][ 3] [ T159] usb 2-1.4: SerialNumber: 03021707022525140940 [ 7.230852][ 0] [ T265] usbcore: registered new interface driver usb-storage [ 7.251247][ 0] [ T265] scsi host3: uas [ 7.255280][ 0] [ T265] usbcore: registered new interface driver uas [ 7.270498][ 1] [ T192] scsi 3:0:0:0: Direct-Access SanDisk Extreme Pro DDE1 0110 PQ: 0 ANSI: 6 [ 7.299588][ 3] [ T192] scsi 3:0:0:1: Enclosure SanDisk SES Device 0110 PQ: 0 ANSI: 6 [ 7.321681][ 3] [ T192] sd 3:0:0:0: Attached scsi generic sg1 type 0 [ 7.328185][ 3] [ T192] scsi 3:0:0:1: Attached scsi generic sg2 type 13 [ 7.328804][ 0] [ T191] sd 3:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB) [ 7.343486][ 0] [ T191] sd 3:0:0:0: [sda] 4096-byte physical blocks [ 7.364611][ 0] [ T191] sd 3:0:0:0: [sda] Write Protect is off [ 7.370524][ 0] [ T191] sd 3:0:0:0: [sda] Mode Sense: 3d 00 10 00 [ 7.390655][ 0] [ T191] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 7.401363][ 0] [ T191] sd 3:0:0:0: [sda] Optimal transfer size 1048576 bytes [ 7.436010][ 0] [ T191] sda: sda1 [ 7.450850][ 0] [ T191] sd 3:0:0:0: [sda] Attached SCSI disk [ 7.470218][ 4] [ T262] scsi 3:0:0:1: Failed to get diagnostic page 0x1 [ 7.474869][ 0] [ C0] sd 3:0:0:0: [sda] tag#0 data cmplt err -75 uas-tag 2 inflight: CMD [ 7.476911][ 4] [ T262] scsi 3:0:0:1: Failed to bind enclosure -19 [ 7.485330][ 0] [ C0] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00 [ 7.491593][ 4] [ T262] ses 3:0:0:1: Attached Enclosure device [ 38.066980][ 4] [ T192] sd 3:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 38.076012][ 4] [ T192] sd 3:0:0:0: [sda] tag#4 CDB: Read(10) 28 00 00 00 01 08 00 00 f8 00 [ 38.086485][ 4] [ T192] sd 3:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 38.095515][ 4] [ T192] sd 3:0:0:0: [sda] tag#3 CDB: Read(10) 28 00 00 00 00 10 00 00 08 00 [ 38.104122][ 4] [ T192] sd 3:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 38.113152][ 4] [ T192] sd 3:0:0:0: [sda] tag#2 CDB: Read(10) 28 00 00 00 00 88 00 00 78 00 [ 38.121761][ 4] [ T192] sd 3:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 38.130791][ 4] [ T192] sd 3:0:0:0: [sda] tag#1 CDB: Read(10) 28 00 00 00 00 48 00 00 30 00 [ 38.139401][ 4] [ T192] sd 3:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD [ 38.148170][ 4] [ T192] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00 [ 38.178980][ 2] [ T304] scsi host3: uas_eh_device_reset_handler start [ 38.901540][ 2] [ T304] usb 2-1.4: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd [ 38.936791][ 2] [ T304] scsi host3: uas_eh_device_reset_handler success Device decriptor is below, Bus 002 Device 006: ID 0781:55e8 SanDisk Corp. SanDisk 3.2 Gen2 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0781 SanDisk Corp. idProduct 0x55e8 bcdDevice 0.01 iManufacturer 1 SanDisk iProduct 2 SanDisk 3.2 Gen2 iSerial 3 03021707022525140940 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0079 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 896mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x002a bNumDeviceCaps 3 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x0000f41e BESL Link Power Management (LPM) Supported BESL value 1024 us Deep BESL value 61440 us SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds SuperSpeedPlus USB Device Capability: bLength 20 bDescriptorType 16 bDevCapabilityType 10 bmAttributes 0x00000001 Sublink Speed Attribute count 1 Sublink Speed ID count 0 wFunctionalitySupport 0x1100 bmSublinkSpeedAttr[0] 0x000a4030 Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus bmSublinkSpeedAttr[1] 0x000a40b0 Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus Device Status: 0x0000 (Bus Powered) So ignore UAS driver for this device. Signed-off-by: Hongyu Xie Cc: stable Link: https://lore.kernel.org/r/20250519023328.1498856-1-xiehongyu1@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit cfd327ad2e001c5f7dac51de58fa8c04e1c96b24 Author: Jiayi Li Date: Thu May 8 13:59:47 2025 +0800 usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE commit 19f795591947596b5b9efa86fd4b9058e45786e9 upstream. This device exhibits I/O errors during file transfers due to unstable link power management (LPM) behavior. The kernel logs show repeated warm resets and eventual disconnection when LPM is enabled: [ 3467.810740] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0020 [ 3467.810740] usb usb2-port5: do warm reset [ 3467.866444] usb usb2-port5: not warm reset yet, waiting 50ms [ 3467.907407] sd 0:0:0:0: [sda] tag#12 sense submit err -19 [ 3467.994423] usb usb2-port5: status 02c0, change 0001, 10.0 Gb/s [ 3467.994453] usb 2-5: USB disconnect, device number 4 The error -19 (ENODEV) occurs when the device disappears during write operations. Adding USB_QUIRK_NO_LPM disables link power management for this specific device, resolving the stability issues. Signed-off-by: Jiayi Li Cc: stable Link: https://lore.kernel.org/r/20250508055947.764538-1-lijiayi@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 0188c74bf3ac9500537e2bde54e4ee8357f333e3 Author: Alexandre Mergnat Date: Mon Apr 28 12:06:48 2025 +0200 rtc: Fix offset calculation for .start_secs < 0 commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream. The comparison rtc->start_secs > rtc->range_max has a signed left-hand side and an unsigned right-hand side. So the comparison might become true for negative start_secs which is interpreted as a (possibly very large) positive value. As a negative value can never be bigger than an unsigned value the correct representation of the (mathematical) comparison rtc->start_secs > rtc->range_max in C is: rtc->start_secs >= 0 && rtc->start_secs > rtc->range_max Use that to fix the offset calculation currently used in the rtc-mt6397 driver. Fixes: 989515647e783 ("rtc: Add one offset seconds to expand RTC range") Signed-off-by: Alexandre Mergnat Reviewed-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-2-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit c360f8ff1bef9fa5d498519208fadd907dc306df Author: Alexandre Mergnat Date: Mon Apr 28 12:06:47 2025 +0200 rtc: Make rtc_time64_to_tm() support dates before 1970 commit 7df4cfef8b351fec3156160bedfc7d6d29de4cce upstream. Conversion of dates before 1970 is still relevant today because these dates are reused on some hardwares to store dates bigger than the maximal date that is representable in the device's native format. This prominently and very soon affects the hardware covered by the rtc-mt6397 driver that can only natively store dates in the interval 1900-01-01 up to 2027-12-31. So to store the date 2028-01-01 00:00:00 to such a device, rtc_time64_to_tm() must do the right thing for time=-2208988800. Signed-off-by: Alexandre Mergnat Reviewed-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-1-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 6df0e243e757d6361fe07c7d3bab694caa674d70 Author: Gautham R. Shenoy Date: Thu May 29 14:21:43 2025 +0530 acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio() commit cb6a85f38f456b086c366e346ebb67ffa70c7243 upstream. commit 083466754596 ("cpufreq: ACPI: Fix max-frequency computation") modified get_max_boost_ratio() to return the nominal_freq advertised in the _CPC object. This was for the purposes of computing the maximum frequency. The frequencies advertised in _CPC objects are in MHz. However, cpufreq expects the frequency to be in KHz. Since the nominal_freq returned by get_max_boost_ratio() was not in KHz but instead in MHz,the cpuinfo_max_frequency that was computed using this nominal_freq was incorrect and an invalid value which resulted in cpufreq reporting the P0 frequency as the cpuinfo_max_freq. Fix this by converting the nominal_freq to KHz before returning the same from get_max_boost_ratio(). Reported-by: Manu Bretelle Closes: https://lore.kernel.org/lkml/aDaB63tDvbdcV0cg@HQ-GR2X1W2P57/ Fixes: 083466754596 ("cpufreq: ACPI: Fix max-frequency computation") Signed-off-by: Gautham R. Shenoy Cc: 6.14+ # 6.14+ Link: https://patch.msgid.link/20250529085143.709-1-gautham.shenoy@amd.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e0a83d422a1887f5237105bbb6eb4544d5a55536 Author: Gabor Juhos Date: Wed May 14 21:18:33 2025 +0200 pinctrl: armada-37xx: set GPIO output value before setting direction commit e6ebd4942981f8ad37189bbb36a3c8495e21ef4c upstream. Changing the direction before updating the output value in the OUTPUT_VAL register may result in a glitch on the output line if the previous value in the OUTPUT_VAL register is different from the one we want to set. In order to avoid that, update the output value before changing the direction. Cc: stable@vger.kernel.org Fixes: 6702abb3bf23 ("pinctrl: armada-37xx: Fix direction_output() callback behavior") Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-2-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit bb9578e9f35f5b344b5a2d851ee5d5c5157bb4bb Author: Gabor Juhos Date: Wed May 14 21:18:32 2025 +0200 pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31 commit 947c93eb29c2a581c0b0b6d5f21af3c2b7ff6d25 upstream. The controller has two consecutive OUTPUT_VAL registers and both holds output value for 32 GPIOs. Due to a missing adjustment, the current code always uses the first register while setting the output value whereas it should use the second one for GPIOs > 31. Add the missing armada_37xx_update_reg() call to adjust the register according to the 'offset' parameter of the function to fix the issue. Cc: stable@vger.kernel.org Fixes: 6702abb3bf23 ("pinctrl: armada-37xx: Fix direction_output() callback behavior") Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-1-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit ebf6f96c7993dd7b5433d1965502d65608ecf171 Author: Pan Taixi Date: Mon May 26 09:37:31 2025 +0800 tracing: Fix compilation warning on arm32 commit 2fbdb6d8e03b70668c0876e635506540ae92ab05 upstream. On arm32, size_t is defined to be unsigned int, while PAGE_SIZE is unsigned long. This hence triggers a compilation warning as min() asserts the type of two operands to be equal. Casting PAGE_SIZE to size_t solves this issue and works on other target architectures as well. Compilation warning details: kernel/trace/trace.c: In function 'tracing_splice_read_pipe': ./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types lacks a cast (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ ./include/linux/minmax.h:26:4: note: in expansion of macro '__typecheck' (__typecheck(x, y) && __no_side_effects(x, y)) ^~~~~~~~~~~ ... kernel/trace/trace.c:6771:8: note: in expansion of macro 'min' min((size_t)trace_seq_used(&iter->seq), ^~~ Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250526013731.1198030-1-pantaixi@huaweicloud.com Fixes: f5178c41bb43 ("tracing: Fix oob write in trace_seq_to_buffer()") Reviewed-by: Jeongjun Park Signed-off-by: Pan Taixi Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman