commit 68efe5a6c16a05391e3d96025b41e9bf573f968c Author: Greg Kroah-Hartman Date: Sun Dec 7 06:09:37 2025 +0900 Linux 5.15.197 Link: https://lore.kernel.org/r/20251203152414.082328008@linuxfoundation.org Tested-by: Hardik Garg Tested-by: Shuah Khan Tested-by: Ron Economos Link: https://lore.kernel.org/r/20251204163821.402208337@linuxfoundation.org Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 3b7841a78357f412741ff0c9a47dbfc53bfbad3a Author: Daniel T. Lee Date: Sat Dec 24 16:15:27 2022 +0900 libbpf: Fix invalid return address register in s390 commit 7244eb669397f309c3d014264823cdc9cb3f8e6b upstream. There is currently an invalid register mapping in the s390 return address register. As the manual[1] states, the return address can be found at r14. In bpf_tracing.h, the s390 registers were named gprs(general purpose registers). This commit fixes the problem by correcting the mistyped mapping. [1]: https://uclibc.org/docs/psABI-s390x.pdf#page=14 Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions") Signed-off-by: Daniel T. Lee Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20221224071527.2292-7-danieltimlee@gmail.com Signed-off-by: Greg Kroah-Hartman commit 46d78c07ce40a899e75cafc1b5e194ed107c32bb Author: Yixun Lan Date: Wed Jul 6 22:02:04 2022 +0800 libbpf, riscv: Use a0 for RC register commit 935dc35c75318fa213d26808ad8bb130fb0b486e upstream. According to the RISC-V calling convention register usage here [0], a0 is used as return value register, so rename it to make it consistent with the spec. [0] section 18.2, table 18.2 https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf Fixes: 589fed479ba1 ("riscv, libbpf: Add RISC-V (RV64) support to bpf_tracing.h") Signed-off-by: Yixun Lan Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Amjad OULED-AMEUR Link: https://lore.kernel.org/bpf/20220706140204.47926-1-dlan@gentoo.org Signed-off-by: Greg Kroah-Hartman commit 9e11d30ab09698b3ebc2b47d1d72a2b5ec0eb24e Author: Ilya Leoshkevich Date: Wed Feb 9 03:17:40 2022 +0100 libbpf: Fix riscv register names commit 5c101153bfd67387ba159b7864176217a40757da upstream. riscv registers are accessed via struct user_regs_struct, not struct pt_regs. The program counter member in this struct is called pc, not epc. The frame pointer is called s0, not fp. Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions") Signed-off-by: Ilya Leoshkevich Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220209021745.2215452-6-iii@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit aadc10434cd1430fb55b188b95c076fb74a56c9b Author: Andrii Nakryiko Date: Thu Jan 6 12:51:56 2022 -0800 selftests/bpf: Don't rely on preserving volatile in PT_REGS macros in loop3 commit 70bc793382a0e37ba4e35e4d1a317b280b829a44 upstream. PT_REGS*() macro on some architectures force-cast struct pt_regs to other types (user_pt_regs, etc) and might drop volatile modifiers, if any. Volatile isn't really required as pt_regs value isn't supposed to change during the BPF program run, so this is correct behavior. But progs/loop3.c relies on that volatile modifier to ensure that loop is preserved. Fix loop3.c by declaring i and sum variables as volatile instead. It preserves the loop and makes the test pass on all architectures (including s390x which is currently broken). Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220106205156.955373-1-andrii@kernel.org Signed-off-by: Greg Kroah-Hartman commit a5d954802bda1aabcba49633cd94bad91c94113f Author: Igor Pylypiv Date: Fri Nov 28 17:48:15 2025 +0300 scsi: pm80xx: Set phy->enable_completion only when we [ Upstream commit e4f949ef1516c0d74745ee54a0f4882c1f6c7aea ] pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. Signed-off-by: Igor Pylypiv Signed-off-by: Terrence Adams Link: https://lore.kernel.org/r/20240627155924.2361370-2-tadamsjr@google.com Acked-by: Jack Wang Signed-off-by: Martin K. Petersen Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman commit f7b814a132c5eda280cc73df205d999d27724095 Author: Alex Lu Date: Fri Nov 28 17:45:34 2025 +0300 Bluetooth: Add more enc key size check [ Upstream commit 04a342cc49a8522e99c9b3346371c329d841dcd2 ] When we are slave role and receives l2cap conn req when encryption has started, we should check the enc key size to avoid KNOB attack or BLUFFS attack. >From SIG recommendation, implementations are advised to reject service-level connections on an encrypted baseband link with key strengths below 7 octets. A simple and clear way to achieve this is to place the enc key size check in hci_cc_read_enc_key_size() The btmon log below shows the case that lacks enc key size check. > HCI Event: Connect Request (0x04) plen 10 Address: BB:22:33:44:55:99 (OUI BB-22-33) Class: 0x480104 Major class: Computer (desktop, notebook, PDA, organizers) Minor class: Desktop workstation Capturing (Scanner, Microphone) Telephony (Cordless telephony, Modem, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 Address: BB:22:33:44:55:99 (OUI BB-22-33) Role: Peripheral (0x01) > HCI Event: Command Status (0x0f) plen 4 Accept Connection Request (0x01|0x0009) ncmd 2 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Link type: ACL (0x01) Encryption: Disabled (0x00) ... > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Encryption: Enabled with E0 (0x01) < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2 Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 2 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Key size: 6 // We should check the enc key size ... > ACL Data RX: Handle 1 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 3 len 4 PSM: 25 (0x0019) Source CID: 64 < ACL Data TX: Handle 1 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 3 len 8 Destination CID: 64 Source CID: 64 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Count: 1 #35: len 16 (25 Kb/s) Latency: 5 msec (2-7 msec ~4 msec) < ACL Data TX: Handle 1 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 3 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000) Cc: stable@vger.kernel.org Signed-off-by: Alex Lu Signed-off-by: Max Chou Signed-off-by: Luiz Augusto von Dentz [ Nazar Kalashnikov: change status to rp_status due to function parameter conflict ] Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman commit 4df96f1f47a45188266421fca5ea69fb7bb0e70d Author: Jameson Thies Date: Mon Dec 1 19:58:41 2025 -0500 usb: typec: ucsi: psy: Set max current to zero when disconnected [ Upstream commit 23379a17334fc24c4a9cbd9967d33dcd9323cc7c ] The ucsi_psy_get_current_max function defaults to 0.1A when it is not clear how much current the partner device can support. But this does not check the port is connected, and will report 0.1A max current when nothing is connected. Update ucsi_psy_get_current_max to report 0A when there is no connection. Fixes: af833e7f7db3 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Reviewed-by: Heikki Krogerus Reviewed-by: Sebastian Reichel Tested-by: Kenneth R. Crudup Rule: add Link: https://lore.kernel.org/stable/20251017000051.2094101-1-jthies%40google.com Link: https://patch.msgid.link/20251106011446.2052583-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman [ adapted UCSI_CONSTAT() macro to direct flag access ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd5e86e34c66a831b5cb9b720ad411a006962cc8 Author: Claudiu Beznea Date: Mon Dec 1 19:40:54 2025 -0500 usb: renesas_usbhs: Fix synchronous external abort on unbind [ Upstream commit eb9ac779830b2235847b72cb15cf07c7e3333c5e ] A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo "0x1d6b" > idVendor echo "0x0104" > idProduct mkdir -p strings/0x409 echo "0123456789" > strings/0x409/serialnumber echo "Renesas." > strings/0x409/manufacturer echo "Ethernet Gadget" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo "ECM" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove. Cc: stable Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20251027140741.557198-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd6a1b29fa313fcb125f9f9b753f911997747c77 Author: Uwe Kleine-König Date: Mon Dec 1 19:40:53 2025 -0500 usb: renesas_usbhs: Convert to platform remove callback returning void [ Upstream commit 456a91ce7de4b9157fd5013c1e4dd8dd3c6daccb ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20230517230239.187727-89-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: eb9ac779830b ("usb: renesas_usbhs: Fix synchronous external abort on unbind") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d146e96fef876492979658dce644305de35878d4 Author: Paulo Alcantara Date: Mon Dec 1 17:09:13 2025 -0500 smb: client: fix memory leak in cifs_construct_tcon() [ Upstream commit 3184b6a5a24ec9ee74087b2a550476f386df7dc2 ] When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: f2aee329a68f ("cifs: set domainName when a domain-key is used in multiuser") Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Cc: Jay Shin Cc: stable@vger.kernel.org Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French [ applied fix to fs/cifs/connect.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7ee8f015eb47907745e2070184a8ab1e442ac3c4 Author: Jiayuan Chen Date: Mon Dec 1 12:27:13 2025 +0100 mptcp: Fix proto fallback detection with BPF commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream. The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]--- Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash") Signed-off-by: Jiayuan Chen Signed-off-by: Martin KaFai Lau Reviewed-by: Jakub Sitnicki Reviewed-by: Matthieu Baerts (NGI0) Cc: Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev [ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It changes the logic on how and where the sock_ops is overridden in case of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use the family, but first, a check of the protocol is required to continue returning 'false' in case of MPTCP socket. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit dad1e44ed940bbba1bfdfaddf01ae2db78ee6e99 Author: Paolo Abeni Date: Sat Nov 29 17:58:26 2025 +0100 mptcp: avoid unneeded subflow-level drops commit 4f102d747cadd8f595f2b25882eed9bec1675fb1 upstream. The rcv window is shared among all the subflows. Currently, MPTCP sync the TCP-level rcv window with the MPTCP one at tcp_transmit_skb() time. The above means that incoming data may sporadically observe outdated TCP-level rcv window and being wrongly dropped by TCP. Address the issue checking for the edge condition before queuing the data at TCP level, and eventually syncing the rcv window as needed. Note that the issue is actually present from the very first MPTCP implementation, but backports older than the blamed commit below will range from impossible to useless. Before: $ nstat -n; sleep 1; nstat -z TcpExtBeyondWindow TcpExtBeyondWindow 14 0.0 After: $ nstat -n; sleep 1; nstat -z TcpExtBeyondWindow TcpExtBeyondWindow 0 0.0 Fixes: fa3fe2b15031 ("mptcp: track window announced to peer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-2-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ Conflicts in options.c, because the new rwin_update() helper has been added after __mptcp_snd_una_update() which is not in this version -- see commit -- and then causing conflicts in the context. There were also some conflicts in mptcp_set_rwin(), because commit f3589be0c420 ("mptcp: never shrink offered window") is not in this version. Only the update of subflow->rcv_wnd_sent has been added. Also msk->rcv_wnd_sent is a u64 before this commit: in rwin_update(), READ_ONCE() is used instead of atomic64_read(&). ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 5bd1d0ca17f0c599c00614e0d66e140b26d8260f Author: Matthieu Baerts (NGI0) Date: Sat Nov 29 17:57:30 2025 +0100 selftests: mptcp: join: rm: set backup flag commit aea73bae662a0e184393d6d7d0feb18d2577b9b9 upstream. Some of these 'remove' tests rarely fail because a subflow has been reset instead of cleanly removed. This can happen when one extra subflow which has never carried data is being closed (FIN) on one side, while the other is sending data for the first time. To avoid such subflows to be used right at the end, the backup flag has been added. With that, data will be only carried on the initial subflow. Fixes: d2c4333a801c ("selftests: mptcp: add testcases for removing addrs") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-2-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski [ The subtests structure has changed quite a bit in newer versions, see commit c7d49c033de0 ("selftests: mptcp: join: alt. to exec specific tests") and commit ae7bd9ccecc3 ("selftests: mptcp: join: option to execute specific tests") for example. To resolve the conflicts, the same principle has been applied: adding ',backup' for each non-ID0 endpoint in remove_tests. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 85cc2f990287310ecf587d3d231e9a150bf077ce Author: Philipp Hortmann Date: Thu Nov 27 15:04:50 2025 -0800 staging: rtl8712: Remove driver using deprecated API wext commit 41e883c137ebe6eec042658ef750cbb0529f6ca8 upstream. This driver is in the staging area since 2010. The following reasons lead to the removal: - This driver generates maintenance workload for itself and for API wext - A MAC80211 driver was available in 2016 time frame; This driver does not compile anymore but would be a better starting point than the current driver. Here the note from the TODO file: A replacement for this driver with MAC80211 support is available at https://github.com/chunkeey/rtl8192su - no progress changing to mac80211 - Using this hardware is security wise not state of the art as WPA3 is not supported. Find further discussions in the Link below. Link: https://lore.kernel.org/linux-staging/a02e3e0b-8a9b-47d5-87cf-2c957a474daa@gmail.com/T/#t Signed-off-by: Philipp Hortmann Tested-by: Dominik Karol Piątkowski Link: https://lore.kernel.org/r/20241020144933.10956-1-philipp.g.hortmann@gmail.com Signed-off-by: Greg Kroah-Hartman [groeck: Resolved conflicts; dropped statement about hardware support in longterm kernels] Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/stable/20251204021604.GA843400@ax162/T/#t Signed-off-by: Greg Kroah-Hartman commit f22c55a20a2d9ffbbac57408d5d488cef8201e9d Author: ziming zhang Date: Fri Nov 14 16:56:10 2025 +0800 libceph: prevent potential out-of-bounds writes in handle_auth_session_key() commit 7fce830ecd0a0256590ee37eb65a39cbad3d64fc upstream. The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ] Cc: stable@vger.kernel.org Signed-off-by: ziming zhang Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 05ec43e9a9de67132dc8cd3b22afef001574947f Author: Ilya Dryomov Date: Mon Nov 3 21:34:01 2025 +0100 libceph: fix potential use-after-free in have_mon_and_osd_map() commit 076381c261374c587700b3accf410bdd2dba334e upstream. The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well. Cc: stable@vger.kernel.org Reported-by: David Howells Signed-off-by: Ilya Dryomov Reviewed-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit 09092269cb762378ca8b56024746b1a136761e0d Author: Alex Hung Date: Fri Nov 7 15:35:58 2025 -0700 drm/amd/display: Check NULL before accessing commit 3ce62c189693e8ed7b3abe551802bbc67f3ace54 upstream. [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c9a315a56da21d5e89f6884a9ba81ea1ed5f89f6 Author: Johan Hovold Date: Mon Sep 22 14:20:12 2025 +0200 drm: sti: fix device leaks at component probe commit 620a8f131154250f6a64a07d049a4f235d6451a5 upstream. Make sure to drop the references taken to the vtg devices by of_find_device_by_node() when looking up their driver data during component probe. Note that holding a reference to a platform device does not prevent its driver data from going away so there is no point in keeping the reference after the lookup helper returns. Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: stable@vger.kernel.org # 4.16 Cc: Benjamin Gaignard Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20250922122012.27407-1-johan@kernel.org Signed-off-by: Raphael Gallais-Pou Signed-off-by: Greg Kroah-Hartman commit 6176101b519f0419b020b487da05a46947a22f4c Author: Vanillan Wang Date: Mon Nov 10 12:20:41 2025 +0800 USB: serial: option: add support for Rolling RW101R-GL commit 523bf0a59e674b52e4b5607a2aba655fbfa20ff2 upstream. - VID:PID 33f8:0301, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x0301: mbim, pipe T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=33f8 ProdID=0301 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms - VID:PID 33f8:01a8, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x01a8: mbim, diag, AT, ADB, pipe1, pipe2 T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=33f8 ProdID=01a8 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=89(I) Atr=03(Int.) MxPS= 10 Ivl=32ms - VID:PID 33f8:0302, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x0302: mbim, pipe T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=0302 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms - VID:PID 33f8:01a9, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x01a9: mbim, diag, AT, ADB, pipe1, pipe2 T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=01a9 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Vanillan Wang Cc: stable@vger.kernel.org [ johan: sort vendor entries, edit commit message slightly ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6738408111c28324a6457e7e1cc50ca48cc58c05 Author: Oleksandr Suvorov Date: Thu Oct 30 17:42:54 2025 +0200 USB: serial: ftdi_sio: add support for u-blox EVK-M101 commit 2d8ab771d5316de64f3bb920b82575c58eb00b1b upstream. The U-Blox EVK-M101 enumerates as 1546:0506 [1] with four FTDI interfaces: - EVK-M101 current sensors - EVK-M101 I2C - EVK-M101 UART - EVK-M101 port D Only the third USB interface is a UART. This change lets ftdi_sio probe the VID/PID and registers only interface #3 as a TTY, leaving the rest available for other drivers. [1] usb 5-1.3: new high-speed USB device number 11 using xhci_hcd usb 5-1.3: New USB device found, idVendor=1546, idProduct=0506, bcdDevice= 8.00 usb 5-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 5-1.3: Product: EVK-M101 usb 5-1.3: Manufacturer: u-blox AG Datasheet: https://content.u-blox.com/sites/default/files/documents/EVK-M10_UserGuide_UBX-21003949.pdf Signed-off-by: Oleksandr Suvorov Link: https://lore.kernel.org/20250926060235.3442748-1-cryosay@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 593d93b871dcc8be732bdd05b10326270241a492 Author: Mathias Nyman Date: Fri Nov 7 18:28:17 2025 +0200 xhci: dbgtty: Fix data corruption when transmitting data form DbC to host commit f6bb3b67be9af0cfb90075c60850b6af5338a508 upstream. Data read from a DbC device may be corrupted due to a race between ongoing write and write request completion handler both queuing new transfer blocks (TRBs) if there are remining data in the kfifo. TRBs may be in incorrct order compared to the data in the kfifo. Driver fails to keep lock between reading data from kfifo into a dbc request buffer, and queuing the request to the transfer ring. This allows completed request to re-queue itself in the middle of an ongoing transfer loop, forcing itself between a kfifo read and request TRB write of another request cpu0 cpu1 (re-queue completed req2) lock(port_lock) dbc_start_tx() kfifo_out(fifo, req1->buffer) unlock(port_lock) lock(port_lock) dbc_write_complete(req2) dbc_start_tx() kfifo_out(fifo, req2->buffer) unlock(port_lock) lock(port_lock) req2->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) lock(port_lock) req1->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) In the above scenario a kfifo containing "12345678" would read "1234" to req1 and "5678" to req2, but req2 is queued before req1 leading to data being transmitted as "56781234" Solve this by adding a flag that prevents starting a new tx if we are already mid dbc_start_tx() during the unlocked part. The already running dbc_do_start_tx() will make sure the newly completed request gets re-queued as it is added to the request write_pool while holding the lock. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251107162819.1362579-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 67192e8cb7f941b5bba91e4bb290683576ce1607 Author: Manish Nagar Date: Thu Nov 20 13:14:35 2025 +0530 usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths commit e4037689a366743c4233966f0e74bc455820d316 upstream. This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable Suggested-by: Thinh Nguyen Acked-by: Thinh Nguyen Signed-off-by: Manish Nagar Link: https://patch.msgid.link/20251120074435.1983091-1-manish.nagar@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 66ac05e7b0d6bbd1bee9fcf729e20fd4cce86d17 Author: Owen Gu Date: Thu Nov 20 20:33:36 2025 +0800 usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer commit 26d56a9fcb2014b99e654127960aa0a48a391e3c upstream. When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete(). Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub") Cc: stable Signed-off-by: Yu Chen Signed-off-by: Owen Gu Acked-by: Oliver Neukum Link: https://patch.msgid.link/20251120123336.3328-1-guhuinan@xiaomi.com Signed-off-by: Greg Kroah-Hartman commit 26e9b5da3231da7dc357b363883b5b7b51a64092 Author: Tianchu Chen Date: Sun Nov 16 12:46:18 2025 +0800 usb: storage: sddr55: Reject out-of-bound new_pba commit b59d4fda7e7d0aff1043a7f742487cb829f5aac1 upstream. Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries. Signed-off-by: Tianchu Chen Cc: stable Link: https://patch.msgid.link/B2DC73A3EE1E3A1D+202511161322001664687@tencent.com Signed-off-by: Greg Kroah-Hartman commit 4aa7426f5326c198d3e5faf65003336b2403c34b Author: Alan Stern Date: Fri Nov 21 16:29:34 2025 -0500 USB: storage: Remove subclass and protocol overrides from Novatek quirk commit df5fde297e617041449f603ed5f646861c80000b upstream. A report from Oleg Smirnov indicates that the unusual_devs quirks entry for the Novatek camera does not need to override the subclass and protocol parameters: [3266355.209532] usb 1-3: new high-speed USB device number 10 using xhci_hcd [3266355.333031] usb 1-3: New USB device found, idVendor=0603, idProduct=8611, bcdDevice= 1.00 [3266355.333040] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3266355.333043] usb 1-3: Product: YICARCAM [3266355.333045] usb 1-3: Manufacturer: XIAO-YI [3266355.333047] usb 1-3: SerialNumber: 966110000000100 [3266355.338621] usb-storage 1-3:1.0: USB Mass Storage device detected [3266355.338817] usb-storage 1-3:1.0: Quirks match for vid 0603 pid 8611: 4000 [3266355.338821] usb-storage 1-3:1.0: This device (0603,8611,0100 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h (kernel 6.16.10-arch1-1) Please send a copy of this message to and The overrides are harmless but they do provoke the driver into logging this annoying message. Update the entry to remove the unneeded entries. Reported-by: stealth Closes: https://lore.kernel.org/CAKxjRRxhC0s19iEWoN=pEMqXJ_z8w_moC0GCXSqSKCcOddnWjQ@mail.gmail.com/ Fixes: 6ca8af3c8fb5 ("USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera") Signed-off-by: Alan Stern Cc: stable Link: https://patch.msgid.link/b440f177-f0b8-4d5a-8f7b-10855d4424ee@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 4ba515dfff7eeca369ab85cdbb3f3b231c71720c Author: Desnes Nunes Date: Fri Oct 31 01:34:36 2025 -0300 usb: storage: Fix memory leak in USB bulk transport commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream. A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable Signed-off-by: Desnes Nunes Reviewed-by: Alan Stern Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com Signed-off-by: Greg Kroah-Hartman commit 5a1628283cd9dccf1e44acfb74e77504f4dc7472 Author: Kuen-Han Tsai Date: Mon Nov 3 20:17:59 2025 +0800 usb: gadget: f_eem: Fix memory leak in eem_unwrap commit e4f5ce990818d37930cd9fb0be29eee0553c59d9 upstream. The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c Fixes: 4249d6fbc10f ("usb: gadget: eem: fix echo command packet response issue") Cc: stable@kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20251103121814.1559719-1-khtsai@google.com Signed-off-by: Greg Kroah-Hartman commit 7fb4b54bbf078a42ba8c074840cd64306e753cf0 Author: Miaoqian Lin Date: Sun Oct 26 17:08:59 2025 +0800 usb: cdns3: Fix double resource release in cdns3_pci_probe commit 1ec39d2cd88dac2e7cdbac248762f1f057971c5d upstream. The driver uses pcim_enable_device() to enable the PCI device, the device will be automatically disabled on driver detach through the managed device framework. The manual pci_disable_device() calls in the error paths are therefore redundant and should be removed. Found via static anlaysis and this is similar to commit 99ca0b57e49f ("thermal: intel: int340x: processor: Fix warning during module unload"). Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Miaoqian Lin Acked-by: Peter Chen Link: https://patch.msgid.link/20251026090859.33107-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman commit a4c4118c2af284835b16431bbfe77e0130c06fef Author: Johan Hovold Date: Wed Oct 29 10:30:29 2025 +0100 most: usb: fix double free on late probe failure commit baadf2a5c26e802a46573eaad331b427b49aaa36 upstream. The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures. Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Fixes: 4b1270902609 ("most: usb: Fix use-after-free in hdm_disconnect") Fixes: a8cc9e5fcb0e ("most: usb: hdm_probe: Fix calling put_device() before device initialization") Cc: stable@vger.kernel.org Cc: Christian Gromm Cc: Victoria Votokina Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251029093029.28922-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1f9ba65b019f6a09d952bc2c79fa4198b86f9ede Author: Miaoqian Lin Date: Mon Oct 27 17:20:50 2025 +0800 serial: amba-pl011: prefer dma_mapping_error() over explicit address checking commit eb4917f557d43c7a1c805dd73ffcdfddb2aba39a upstream. Check for returned DMA addresses using specialized dma_mapping_error() helper which is generally recommended for this purpose by Documentation/core-api/dma-api.rst: "In some circumstances dma_map_single(), ... will fail to create a mapping. A driver can check for these errors by testing the returned DMA address with dma_mapping_error()." Found via static analysis and this is similar to commit fa0308134d26 ("ALSA: memalloc: prefer dma_mapping_error() over explicit address checking") Fixes: 58ac1b379979 ("ARM: PL011: Fix DMA support") Cc: stable Signed-off-by: Miaoqian Lin Reviewed-by: Gregory CLEMENT Link: https://patch.msgid.link/20251027092053.87937-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman commit 354fb03002da0970d337f0d3edbeb46cc4fa6f41 Author: Khairul Anuar Romli Date: Mon Nov 3 07:21:28 2025 +0800 firmware: stratix10-svc: fix bug in saving controller data commit d0fcf70c680e4d1669fcb3a8632f41400b9a73c2 upstream. Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free. Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features") Cc: stable@vger.kernel.org # 6.6+ Signed-off-by: Ang Tien Sung Signed-off-by: Khairul Anuar Romli Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 113f10c86d7d9fb388a6bf42fa43cba78dfa8bb7 Author: Miaoqian Lin Date: Mon Oct 27 14:06:01 2025 +0800 slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves commit 96cf8500934e0ce2a6c486f1dbc3b1fff12f7a5e upstream. The function qcom_slim_ngd_notify_slaves() calls of_slim_get_device() which internally uses device_find_child() to obtain a device reference. According to the device_find_child() documentation, the caller must drop the reference with put_device() after use. Found via static analysis and this is similar to commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable Signed-off-by: Miaoqian Lin Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20251027060601.33228-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit db0835dfac45caf839ee1fddf8bce6b1f26fe7c1 Author: Alan Borzeszkowski Date: Thu Nov 14 10:55:44 2024 +0100 thunderbolt: Add support for Intel Wildcat Lake commit 3575254546a27210a4b661ea37fbbfb836c0815d upstream. Intel Wildcat Lake derives its Thunderbolt/USB4 controller from Lunar Lake platform. Add Wildcat Lake PCI ID to the driver list of supported devices. Signed-off-by: Alan Borzeszkowski Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 5a0dcabc8a1463a09bcdb82e973551b7cf9b8479 Author: Jamie Iles Date: Fri Nov 7 10:44:37 2025 +0000 drivers/usb/dwc3: fix PCI parent check commit 40f8d17eed7533ed2bbb5e3cc680049b19411b2e upstream. The sysdev_is_parent check was being used to infer PCI devices that have the DMA mask set from the PCI capabilities, but sysdev_is_parent is also used for non-PCI ACPI devices in which case the DMA mask would be the bus default or as set by the _DMA method. Without this fix the DMA mask would default to 32-bits and so allocation would fail if there was no DRAM below 4GB. Fixes: 47ce45906ca9 ("usb: dwc3: leave default DMA for PCI devices") Cc: stable Signed-off-by: Jamie Iles Signed-off-by: Punit Agrawal Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20251107104437.1602509-1-punit.agrawal@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit ed69c3db499ca29a5c7769110cf9c1dbc4c9c6a3 Author: Mikulas Patocka Date: Mon Nov 17 21:42:02 2025 +0100 dm-verity: fix unreliable memory allocation commit fe680d8c747f4e676ac835c8c7fb0f287cd98758 upstream. GFP_NOWAIT allocation may fail anytime. It needs to be changed to GFP_NOIO. There's no need to handle an error because mempool_alloc with GFP_NOIO can't fail. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Reviewed-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 6fdcd310f92a8f4ddf466ec07295baa5a55b3c25 Author: Marc Kleine-Budde Date: Sun Nov 16 16:55:26 2025 +0100 can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling commit 76544beea7cfe5bcce6d60f53811657b88ec8be1 upstream. Reading the interrupt register `SUN4I_REG_INT_ADDR` causes all of its bits to be reset. If we ever reach the condition of handling more than `SUN4I_CAN_MAX_IRQ` IRQs, we will have read the register and reset all its bits but without actually handling the interrupt inside of the loop body. This may, among other issues, cause us to never `netif_wake_queue()` again after a transmission interrupt. Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module") Cc: stable@vger.kernel.org Co-developed-by: Thomas Mühlbacher Signed-off-by: Thomas Mühlbacher Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20251116-sun4i-fix-loop-v1-1-3d76d3f81950@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e36369dfa2e72cf6254f7cfa69ae5f82600a92ac Author: Thomas Mühlbacher Date: Sat Nov 15 15:34:56 2025 +0000 can: sja1000: fix max irq loop handling commit 30db4451c7f6aabcada029b15859a76962ec0cf8 upstream. Reading the interrupt register `SJA1000_IR` causes all of its bits to be reset. If we ever reach the condition of handling more than `SJA1000_MAX_IRQ` IRQs, we will have read the register and reset all its bits but without actually handling the interrupt inside of the loop body. This may, among other issues, cause us to never `netif_wake_queue()` again after a transmission interrupt. Fixes: 429da1cc841b ("can: Driver for the SJA1000 CAN controller") Cc: stable@vger.kernel.org Signed-off-by: Thomas Mühlbacher Acked-by: Oliver Hartkopp Link: https://patch.msgid.link/20251115153437.11419-1-tmuehlbacher@posteo.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit bd1415efbab507b9b995918105eef953013449dd Author: Gui-Dong Han Date: Thu Nov 20 20:06:57 2025 +0800 atm/fore200e: Fix possible data race in fore200e_open() commit 82fca3d8a4a34667f01ec2351a607135249c9cff upstream. Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251120120657.2462194-1-hanguidong02@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 19f3ace94943d117e6df06764f38b6d53d55a5c3 Author: Maciej W. Rozycki Date: Thu Nov 13 05:21:10 2025 +0000 MIPS: mm: Prevent a TLB shutdown on initial uniquification commit 9f048fa487409e364cf866c957cf0b0d782ca5a3 upstream. Depending on the particular CPU implementation a TLB shutdown may occur if multiple matching entries are detected upon the execution of a TLBP or the TLBWI/TLBWR instructions. Given that we don't know what entries we have been handed we need to be very careful with the initial TLB setup and avoid all these instructions. Therefore read all the TLB entries one by one with the TLBR instruction, bypassing the content addressing logic, and truncate any large pages in place so as to avoid a case in the second step where an incoming entry for a large page at a lower address overlaps with a replacement entry chosen at another index. Then preinitialize the TLB using addresses outside our usual unique range and avoiding clashes with any entries received, before making the usual call to local_flush_tlb_all(). This fixes (at least) R4x00 cores if TLBP hits multiple matching TLB entries (SGI IP22 PROM for examples sets up all TLBs to the same virtual address). Signed-off-by: Maciej W. Rozycki Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init") Cc: stable@vger.kernel.org Reviewed-by: Jiaxun Yang Tested-by: Jiaxun Yang # Boston I6400, M5150 sim Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit aad9d048a3211c48ec02efa405bf462856feb862 Author: Linus Walleij Date: Mon Nov 3 10:36:18 2025 +0100 iio: accel: bmc150: Fix irq assumption regression commit 3aa385a9c75c09b59dcab2ff76423439d23673ab upstream. The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 17a38b85226c166b2fef7dbb135f3278e818b156 Author: Christophe JAILLET Date: Fri Oct 10 20:58:48 2025 +0200 iio:common:ssp_sensors: Fix an error handling path ssp_probe() commit 21553258b94861a73d7f2cf15469d69240e1170d upstream. If an error occurs after a successful mfd_add_devices() call, it should be undone by a corresponding mfd_remove_devices() call, as already done in the remove function. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Christophe JAILLET Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 57f759d399e708feb8c9663b26b0237a625db5ca Author: Francesco Lavra Date: Fri Oct 17 19:32:08 2025 +0200 iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields commit 3af0c1fb1cdc351b64ff1a4bc06d491490c1f10a upstream. The `decimator` and `batch` fields of struct st_lsm6dsx_settings are arrays indexed by sensor type, not by sensor hardware identifier; moreover, the `batch` field is only used for the accelerometer and gyroscope. Change the array size for `decimator` from ST_LSM6DSX_MAX_ID to ST_LSM6DSX_ID_MAX, and change the array size for `batch` from ST_LSM6DSX_MAX_ID to 2; move the enum st_lsm6dsx_sensor_id definition so that the ST_LSM6DSX_ID_MAX value is usable within the struct st_lsm6dsx_settings definition. Fixes: 801a6e0af0c6c ("iio: imu: st_lsm6dsx: add support to LSM6DSO") Signed-off-by: Francesco Lavra Acked-by: Lorenzo Bianconi Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5b9790d2009e1ac61ce93b93eecfa464b972122b Author: Jiri Olsa Date: Tue Nov 4 22:54:02 2025 +0100 Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()" commit 6d08340d1e354787d6c65a8c3cdd4d41ffb8a5ed upstream. This reverts commit 83f44ae0f8afcc9da659799db8693f74847e66b3. Currently we store initial stacktrace entry twice for non-HW ot_regs, which means callers that fail perf_hw_regs(regs) condition in perf_callchain_kernel. It's easy to reproduce this bpftrace: # bpftrace -e 'tracepoint:sched:sched_process_exec { print(kstack()); }' Attaching 1 probe... bprm_execve+1767 bprm_execve+1767 do_execveat_common.isra.0+425 __x64_sys_execve+56 do_syscall_64+133 entry_SYSCALL_64_after_hwframe+118 When perf_callchain_kernel calls unwind_start with first_frame, AFAICS we do not skip regs->ip, but it's added as part of the unwind process. Hence reverting the extra perf_callchain_store for non-hw regs leg. I was not able to bisect this, so I'm not really sure why this was needed in v5.2 and why it's not working anymore, but I could see double entries as far as v5.10. I did the test for both ORC and framepointer unwind with and without the this fix and except for the initial entry the stacktraces are the same. Acked-by: Song Liu Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20251104215405.168643-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Acked-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 891775b1b4edd131ad2f9a3130f0efd1204377ae Author: Hang Zhou <929513338@qq.com> Date: Mon Nov 17 01:08:35 2025 +1100 spi: bcm63xx: fix premature CS deassertion on RX-only transactions [ Upstream commit fd9862f726aedbc2f29a29916cabed7bcf5cadb6 ] On BCM6358 (and also observed on BCM6368) the controller appears to only generate as many SPI clocks as bytes that have been written into the TX FIFO. For RX-only transfers the driver programs the transfer length in SPI_MSG_CTL but does not write anything into the FIFO, so chip select is deasserted early and the RX transfer segment is never fully clocked in. A concrete failing case is a three-transfer MAC address read from SPI-NOR: - TX 0x03 (read command) - TX 3-byte address - RX 6 bytes (MAC) In contrast, a two-transfer JEDEC-ID read (0x9f + 6-byte RX) works because the driver uses prepend_len and writes dummy bytes into the TX FIFO for the RX part. Fix this by writing 0xff dummy bytes into the TX FIFO for RX-only segments so that the number of bytes written to the FIFO matches the total message length seen by the controller. Fixes: b17de076062a ("spi/bcm63xx: work around inability to keep CS up") Signed-off-by: Hang Zhou <929513338@qq.com> Link: https://patch.msgid.link/tencent_7AC88FCB3076489A4A7E6C2163DF1ACF8D06@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f231314b64c5d0c3168847a76916ee52e73b4a7f Author: Haotian Zhang Date: Thu Nov 20 10:40:39 2025 +0800 mailbox: mailbox-test: Fix debugfs_create_dir error checking [ Upstream commit 3acf1028f5003731977f750a7070f3321a9cb740 ] The debugfs_create_dir() function returns ERR_PTR() on error, not NULL. The current null-check fails to catch errors. Use IS_ERR() to correctly check for errors. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Haotian Zhang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit b0c4d5135b04ea100988e2458c98f2d8564cda16 Author: Jiefeng Zhang Date: Wed Nov 26 11:22:49 2025 +0800 net: atlantic: fix fragment overflow handling in RX path [ Upstream commit 5ffcb7b890f61541201461580bb6622ace405aec ] The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Fixes: 6aecbba12b5c ("net: atlantic: add check for MAX_SKB_FRAGS") Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. Signed-off-by: Jiefeng Zhang Link: https://patch.msgid.link/20251126032249.69358-1-jiefeng.z.zhang@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 05c51c116e0b359fbbbdcf7d49407e4d042899ee Author: Vladimir Oltean Date: Sat Nov 22 13:13:24 2025 +0200 net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic [ Upstream commit da62abaaa268357b1aa66b372ace562189a05df1 ] When using the SGMII PCS as a fixed-link chip-to-chip connection, it is easy to miss the fact that traffic passes only at 1G, since that's what any normal such connection would use. When using the SGMII PCS connected towards an on-board PHY or an SFP module, it is immediately noticeable that when the link resolves to a speed other than 1G, traffic from the MAC fails to pass: TX counters increase, but nothing gets decoded by the other end, and no local RX counters increase either. Artificially lowering a fixed-link rate to speed = <100> makes us able to see the same issue as in the case of having an SGMII PHY. Some debugging shows that the XPCS configuration is A-OK, but that the MAC Configuration Table entry for the port has the SPEED bits still set to 1000Mbps, due to a special condition in the driver. Deleting that condition, and letting the resolved link speed be programmed directly into the MAC speed field, results in a functional link at all 3 speeds. This piece of evidence, based on testing on both generations with SGMII support (SJA1105S and SJA1110A) directly contradicts the statement from the blamed commit that "the MAC is fixed at 1 Gbps and we need to configure the PCS only (if even that)". Worse, that statement is not backed by any documentation, and no one from NXP knows what it might refer to. I am unable to recall sufficient context regarding my testing from March 2020 to understand what led me to draw such a braindead and factually incorrect conclusion. Yet, there is nothing of value regarding forcing the MAC speed, either for SGMII or 2500Base-X (introduced at a later stage), so remove all such logic. Fixes: ffe10e679cec ("net: dsa: sja1105: Add support for the SGMII port") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20251122111324.136761-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0bd2b12b3ca97331db43947cb350c3a203c2c738 Author: Russell King (Oracle) Date: Tue Oct 1 17:04:36 2024 +0100 net: dsa: sja1105: simplify static configuration reload [ Upstream commit a18891b55703a45b700618ef40edd5e9aaecc345 ] The static configuration reload saves the port speed in the static configuration tables by first converting it from the internal respresentation to the SPEED_xxx ethtool representation, and then converts it back to restore the setting. This is because sja1105_adjust_port_config() takes the speed as SPEED_xxx. However, this is unnecessarily complex. If we split sja1105_adjust_port_config() up, we can simply save and restore the mac[port].speed member in the static configuration tables. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1svfMa-005ZIX-If@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: da62abaaa268 ("net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic") Signed-off-by: Sasha Levin commit 1989e6ecee9110fd386ed0a0cbcb64b5652efe5f Author: Andrew Lunn Date: Sat Apr 30 19:30:36 2022 +0200 net: dsa: sja1105: Convert to mdiobus_c45_read [ Upstream commit 639e4b93ab68f5f5fc4734c766124ca96c167f14 ] Stop using the helpers to construct a special phy address which indicates C45. Instead use the C45 accessors, which will call the busses C45 specific read/write API. Reviewed-by: Vladimir Oltean Tested-by: Vladimir Oltean Signed-off-by: Andrew Lunn Signed-off-by: Paolo Abeni Stable-dep-of: da62abaaa268 ("net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic") Signed-off-by: Sasha Levin commit 18ef3ad1bb57dcf1a9ee61736039aedccf670b21 Author: Alexey Kodanev Date: Fri Nov 21 12:38:34 2025 +0000 net: sxgbe: fix potential NULL dereference in sxgbe_rx() [ Upstream commit f5bce28f6b9125502abec4a67d68eabcd24b3b17 ] Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Alexey Kodanev Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251121123834.97748-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3c11ac20b5fd06b15a35762f47238456908cb07e Author: Danielle Costantino Date: Mon Nov 24 10:00:43 2025 -0800 net/mlx5e: Fix validation logic in rate limiting [ Upstream commit d2099d9f16dbfa1c5266d4230ff7860047bb0b68 ] The rate limiting validation condition currently checks the output variable max_bw_value[i] instead of the input value maxrate->tc_maxrate[i]. This causes the validation to compare an uninitialized or stale value rather than the actual requested rate. The condition should check the input rate to properly validate against the upper limit: } else if (maxrate->tc_maxrate[i] <= upper_limit_gbps) { This aligns with the pattern used in the first branch, which correctly checks maxrate->tc_maxrate[i] against upper_limit_mbps. The current implementation can lead to unreliable validation behavior: - For rates between 25.5 Gbps and 255 Gbps, if max_bw_value[i] is 0 from initialization, the GBPS path may be taken regardless of whether the actual rate is within bounds - When processing multiple TCs (i > 0), max_bw_value[i] contains the value computed for the previous TC, affecting the validation logic - The overflow check for rates exceeding 255 Gbps may not trigger consistently depending on previous array values This patch ensures the validation correctly examines the requested rate value for proper bounds checking. Fixes: 43b27d1bd88a ("net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps") Signed-off-by: Danielle Costantino Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20251124180043.2314428-1-dcostantino@meta.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58a8e250d5b668e2b44a16e8ea94e3456ff0659f Author: Kai-Heng Feng Date: Thu Nov 20 12:15:33 2025 +0800 net: aquantia: Add missing descriptor cache invalidation on ATL2 [ Upstream commit 7526183cfdbe352c51c285762f0e15b7c428ea06 ] ATL2 hardware was missing descriptor cache invalidation in hw_stop(), causing SMMU translation faults during device shutdown and module removal: [ 70.355743] arm-smmu-v3 arm-smmu-v3.5.auto: event 0x10 received: [ 70.361893] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0002060000000010 [ 70.367948] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000020000000000 [ 70.374002] arm-smmu-v3 arm-smmu-v3.5.auto: 0x00000000ff9bc000 [ 70.380055] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000000000000000 [ 70.386109] arm-smmu-v3 arm-smmu-v3.5.auto: event: F_TRANSLATION client: 0001:06:00.0 sid: 0x20600 ssid: 0x0 iova: 0xff9bc000 ipa: 0x0 [ 70.398531] arm-smmu-v3 arm-smmu-v3.5.auto: unpriv data write s1 "Input address caused fault" stag: 0x0 Commit 7a1bb49461b1 ("net: aquantia: fix potential IOMMU fault after driver unbind") and commit ed4d81c4b3f2 ("net: aquantia: when cleaning hw cache it should be toggled") fixed cache invalidation for ATL B0, but ATL2 was left with only interrupt disabling. This allowed hardware to write to cached descriptors after DMA memory was unmapped, triggering SMMU faults. Once cache invalidation is applied to ATL2, the translation fault can't be observed anymore. Add shared aq_hw_invalidate_descriptor_cache() helper and use it in both ATL B0 and ATL2 hw_stop() implementations for consistent behavior. Fixes: e54dcf4bba3e ("net: atlantic: basic A2 init/deinit hw_ops") Tested-by: Carol Soto Signed-off-by: Kai-Heng Feng Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251120041537.62184-1-kaihengf@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 15d560cdf5b36c51fffec07ac2a983ab3bff4cb2 Author: Dan Carpenter Date: Fri Nov 21 20:51:28 2025 +0300 platform/x86: intel: punit_ipc: fix memory corruption [ Upstream commit 9b9c0adbc3f8a524d291baccc9d0c04097fb4869 ] This passes the address of the pointer "&punit_ipcdev" when the intent was to pass the pointer itself "punit_ipcdev" (without the ampersand). This means that the: complete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it. Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSCmoBipSQ_tlD-D@stanley.mountain Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4475bac8224ce1e43603a94411ab3d781f006326 Author: Luiz Augusto von Dentz Date: Mon Nov 17 13:45:13 2025 -0500 Bluetooth: SMP: Fix not generating mackey and ltk when repairing [ Upstream commit 545d7827b2cd5de5eb85580cebeda6b35b3ff443 ] The change eed467b517e8 ("Bluetooth: fix passkey uninitialized when used") introduced a goto that bypasses the creation of temporary mackey and ltk which are later used by the likes of DHKey Check step. Later ffee202a78c2 ("Bluetooth: Always request for user confirmation for Just Works (LE SC)") which means confirm_hint is always set in case JUST_WORKS so the branch checking for an existing LTK becomes pointless as confirm_hint will always be set, so this just merge both cases of malicious or legitimate devices to be confirmed before continuing with the pairing procedure. Link: https://github.com/bluez/bluez/issues/1622 Fixes: eed467b517e8 ("Bluetooth: fix passkey uninitialized when used") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 69c7825df64e24dc15d31631a1fc9145324b1345 Author: Seungjin Bae Date: Thu Oct 23 12:27:09 2025 -0400 can: kvaser_usb: leaf: Fix potential infinite loop in command parsers [ Upstream commit 0c73772cd2b8cc108d5f5334de89ad648d89b9ec ] The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary. Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c") Signed-off-by: Seungjin Bae Reviewed-by: Jimmy Assarsson Tested-by: Jimmy Assarsson Link: https://patch.msgid.link/20251023162709.348240-1-eeodqql09@gmail.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 0e2d3a8d9fff9d33a9b7f614407482e51ac52c68 Author: Gulam Mohamed Date: Wed Nov 26 17:54:15 2025 +0000 Revert "block: don't add or resize partition on the disk with GENHD_FL_NO_PART" This reverts commit 1a721de8489fa559ff4471f73c58bb74ac5580d3. The commit 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") and the commit 7777f47f2ea6 ("block: Move checking GENHD_FL_NO_PART to bdev_add_partition()") used the flag GENHD_FL_NO_PART to prevent the add or resize of partitions in 5.15 stable kernels.But in these 5.15 kernels, this is giving an issue with the following error where the loop driver wants to create a partition when the partscan is disabled on the loop device: dd if=/dev/zero of=loopDisk.dsk bs=1M count=1 seek=10240; losetup -f loopDisk.dsk;parted -s /dev/loop0 -- mklabel gpt mkpart primary 2048s 4096s 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0016293 s, 644 MB/s "" Error: Partition(s) 1 on /dev/loop0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. "" If the partition scan is not enabled on the loop device, this flag GENHD_FL_NO_PART is getting set and when partition creation is tried, it returns an error EINVAL thereby preventing the creation of partitions. So, there is no such distinction between disabling of partition scan and partition creation. Later in 6.xxx kernels, the commit b9684a71fca7 ("block, loop: support partitions without scanning") a new flag GD_SUPPRESS_PART_SCAN was introduced that just disables the partition scan and uses GENHD_FL_NO_PART only to prevent creating partition scan. So, the partition creationg can proceed with even if partition scan is disabled. As the commit b9684a71fca7 ("block, loop: support partitions without scanning") is not available in 5.15 stable kernel, and since there is no distinction between disabling of "partition scan" and "partition creation", we need to revert the commits 1a721de8489f and 7777f47f2ea6 from 5.15 stable kernel to allow partition creation when partscan is disabled. Cc: stable@vger.kernel.org Signed-off-by: Gulam Mohamed Signed-off-by: Greg Kroah-Hartman commit 91db2663893a61be2ecd3d771e3e247ebd51122c Author: Gulam Mohamed Date: Wed Nov 26 17:54:14 2025 +0000 Revert "block: Move checking GENHD_FL_NO_PART to bdev_add_partition()" This reverts commit 7777f47f2ea64efd1016262e7b59fab34adfb869. The commit 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") and the commit 7777f47f2ea6 ("block: Move checking GENHD_FL_NO_PART to bdev_add_partition()") used the flag GENHD_FL_NO_PART to prevent the add or resize of partitions in 5.15 stable kernels.But in these 5.15 kernels, this is giving an issue with the following error where the loop driver wants to create a partition when the partscan is disabled on the loop device: dd if=/dev/zero of=loopDisk.dsk bs=1M count=1 seek=10240; losetup -f loopDisk.dsk;parted -s /dev/loop0 -- mklabel gpt mkpart primary 2048s 4096s 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0016293 s, 644 MB/s "" Error: Partition(s) 1 on /dev/loop0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. "" If the partition scan is not enabled on the loop device, this flag GENHD_FL_NO_PART is getting set and when partition creation is tried, it returns an error EINVAL thereby preventing the creation of partitions. So, there is no such distinction between disabling of partition scan and partition creation. Later in 6.xxx kernels, the commit b9684a71fca7 ("block, loop: support partitions without scanning") a new flag GD_SUPPRESS_PART_SCAN was introduced that just disables the partition scan and uses GENHD_FL_NO_PART only to prevent creating partition scan. So, the partition creationg can proceed with even if partition scan is disabled. As the commit b9684a71fca7 ("block, loop: support partitions without scanning") is not available in 5.15 stable kernel, and since there is no distinction between disabling of "partition scan" and "partition creation", we need to revert the commits 1a721de8489f and 7777f47f2ea6 from 5.15 stable kernel to allow partition creation when partscan is disabled. Cc: stable@vger.kernel.org Signed-off-by: Gulam Mohamed Signed-off-by: Greg Kroah-Hartman commit 0b6a100efd9b99c34013dac94a6ef90bd05f2d55 Author: Paolo Abeni Date: Mon Nov 24 22:07:11 2025 -0500 mptcp: do not fallback when OoO is present [ Upstream commit 1bba3f219c5e8c29e63afa3c1fc24f875ebec119 ] In case of DSS corruption, the MPTCP protocol tries to avoid the subflow reset if fallback is possible. Such corruptions happen in the receive path; to ensure fallback is possible the stack additionally needs to check for OoO data, otherwise the fallback will break the data stream. Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/598 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-4-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ patch mptcp_dss_corruption() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e2d1ad207174a7cd7903dd27a00db4b2dfa6c64b Author: Eric Dumazet Date: Mon Nov 24 21:39:10 2025 -0500 mptcp: fix a race in mptcp_pm_del_add_timer() [ Upstream commit 426358d9be7ce3518966422f87b96f1bad27295f ] mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2523 [inline] slab_free mm/slub.c:6611 [inline] kfree+0x197/0x950 mm/slub.c:6818 mptcp_remove_anno_list_by_saddr+0x2d/0x40 net/mptcp/pm.c:158 mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_kernel.c:1209 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_kernel.c:1240 [inline] mptcp_pm_nl_flush_addrs_doit+0x593/0xbb0 net/mptcp/pm_kernel.c:1281 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x508/0x820 net/socket.c:2630 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684 __sys_sendmsg net/socket.c:2716 [inline] __do_sys_sendmsg net/socket.c:2721 [inline] __se_sys_sendmsg net/socket.c:2719 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2719 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cc: stable@vger.kernel.org Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Reported-by: syzbot+2a6fbf0f0530375968df@syzkaller.appspotmail.com Closes: https://lore.kernel.org/691ad3c3.a70a0220.f6df1.0004.GAE@google.com Signed-off-by: Eric Dumazet Cc: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251117100745.1913963-1-edumazet@google.com Signed-off-by: Jakub Kicinski [ applied changes to pm_netlink.c instead of pm.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2cc425276ccb5bcb38e90da9c20efd2e99032b73 Author: Paolo Abeni Date: Mon Nov 24 19:48:16 2025 -0500 mptcp: fix premature close in case of fallback [ Upstream commit 17393fa7b7086664be519e7230cb6ed7ec7d9462 ] I'm observing very frequent self-tests failures in case of fallback when running on a CONFIG_PREEMPT kernel. The root cause is that subflow_sched_work_if_closed() closes any subflow as soon as it is half-closed and has no incoming data pending. That works well for regular subflows - MPTCP needs bi-directional connectivity to operate on a given subflow - but for fallback socket is race prone. When TCP peer closes the connection before the MPTCP one, subflow_sched_work_if_closed() will schedule the MPTCP worker to gracefully close the subflow, and shortly after will do another schedule to inject and process a dummy incoming DATA_FIN. On CONFIG_PREEMPT kernel, the MPTCP worker can kick-in and close the fallback subflow before subflow_sched_work_if_closed() is able to create the dummy DATA_FIN, unexpectedly interrupting the transfer. Address the issue explicitly avoiding closing fallback subflows on when the peer is only half-closed. Note that, when the subflow is able to create the DATA_FIN before the worker invocation, the worker will change the msk state before trying to close the subflow and will skip the latter operation as the msk will not match anymore the precondition in __mptcp_close_subflow(). Fixes: f09b0ad55a11 ("mptcp: close subflow when receiving TCP+FIN") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-3-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ sk -> ssk ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c3d91386d1882034eba0ab56865fbab38aca6db Author: Paolo Abeni Date: Mon Nov 24 17:39:38 2025 -0500 mptcp: fix ack generation for fallback msk [ Upstream commit 5e15395f6d9ec07395866c5511f4b4ac566c0c9b ] mptcp_cleanup_rbuf() needs to know the last most recent, mptcp-level rcv_wnd sent, and such information is tracked into the msk->old_wspace field, updated at ack transmission time by mptcp_write_options(). Fallback socket do not add any mptcp options, such helper is never invoked, and msk->old_wspace value remain stale. That in turn makes ack generation at recvmsg() time quite random. Address the issue ensuring mptcp_write_options() is invoked even for fallback sockets, and just update the needed info in such a case. The issue went unnoticed for a long time, as mptcp currently overshots the fallback socket receive buffer autotune significantly. It is going to change in the near future. Fixes: e3859603ba13 ("mptcp: better msk receive window updates") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/594 Signed-off-by: Paolo Abeni Reviewed-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-1-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fab9232b3f27e944cfb00663e0bee898a253d696 Author: Krzysztof Kozlowski Date: Mon Nov 24 16:18:06 2025 -0500 dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups [ Upstream commit 316e361b5d2cdeb8d778983794a1c6eadcb26814 ] The "groups" property can hold multiple entries (e.g. toshiba/tmpv7708-rm-mbrc.dts file), so allow that by dropping incorrect type (pinmux-node.yaml schema already defines that as string-array) and adding constraints for items. This fixes dtbs_check warnings like: toshiba/tmpv7708-rm-mbrc.dtb: pinctrl@24190000 (toshiba,tmpv7708-pinctrl): pwm-pins:groups: ['pwm0_gpio16_grp', 'pwm1_gpio17_grp', 'pwm2_gpio18_grp', 'pwm3_gpio19_grp'] is too long Fixes: 1825c1fe0057 ("pinctrl: Add DT bindings for Toshiba Visconti TMPV7700 SoC") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Acked-by: Conor Dooley Signed-off-by: Linus Walleij [ adjusted $ref context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 444c875c347cc036baccc065a6fa6844a2b39bd8 Author: Niklas Cassel Date: Mon Nov 24 13:48:38 2025 -0500 ata: libata-scsi: Fix system suspend for a security locked drive [ Upstream commit b11890683380a36b8488229f818d5e76e8204587 ] Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") fixed ata_to_sense_error() to properly generate sense key ABORTED COMMAND (without any additional sense code), instead of the previous bogus sense key ILLEGAL REQUEST with the additional sense code UNALIGNED WRITE COMMAND, for a failed command. However, this broke suspend for Security locked drives (drives that have Security enabled, and have not been Security unlocked by boot firmware). The reason for this is that the SCSI disk driver, for the Synchronize Cache command only, treats any sense data with sense key ILLEGAL REQUEST as a successful command (regardless of ASC / ASCQ). After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") the code that treats any sense data with sense key ILLEGAL REQUEST as a successful command is no longer applicable, so the command fails, which causes the system suspend to be aborted: sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5 sd 1:0:0:0: PM: failed to suspend async: error -5 PM: Some devices failed to suspend, or early wake event detected To make suspend work once again, for a Security locked device only, return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense data which a real SCSI device would have returned if locked. The SCSI disk driver treats this sense data as a successful command. Cc: stable@vger.kernel.org Reported-by: Ilia Baryshnikov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704 Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") Reviewed-by: Hannes Reinecke Reviewed-by: Martin K. Petersen Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 015b719962696b793997e8deefac019f816aca77 Author: Seungjin Bae Date: Mon Nov 24 13:37:58 2025 -0500 Input: pegasus-notetaker - fix potential out-of-bounds access [ Upstream commit 69aeb507312306f73495598a055293fa749d454e ] In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access. Fixes: 1afca2b66aac ("Input: add Pegasus Notetaker tablet driver") Signed-off-by: Seungjin Bae Link: https://lore.kernel.org/r/20251007214131.3737115-2-eeodqql09@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7bf70ce0a08e35dc6aa6f0491bdafc7453769892 Author: Vincent Mailhol Date: Mon Nov 24 13:37:57 2025 -0500 Input: remove third argument of usb_maxpacket() [ Upstream commit 948bf187694fc1f4c20cf972fa18b1a6fb3d7603 ] The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Ville Syrjala CC: Dmitry Torokhov CC: Henk Vergonet Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/r/20220317035514.6378-4-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 69aeb5073123 ("Input: pegasus-notetaker - fix potential out-of-bounds access") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78acf73dfc3086065d0957334b23f721c4181905 Author: Vincent Mailhol Date: Mon Nov 24 13:37:56 2025 -0500 usb: deprecate the third argument of usb_maxpacket() [ Upstream commit 0f08c2e7458e25c967d844170f8ad1aac3b57a02 ] This is a transitional patch with the ultimate goal of changing the prototype of usb_maxpacket() from: | static inline __u16 | usb_maxpacket(struct usb_device *udev, int pipe, int is_out) into: | static inline u16 usb_maxpacket(struct usb_device *udev, int pipe) The third argument of usb_maxpacket(): is_out gets removed because it can be derived from its second argument: pipe using usb_pipeout(pipe). Furthermore, in the current version, ubs_pipeout(pipe) is called regardless in order to sanitize the is_out parameter. In order to make a smooth change, we first deprecate the is_out parameter by simply ignoring it (using a variadic function) and will remove it later, once all the callers get updated. The body of the function is reworked accordingly and is_out is replaced by usb_pipeout(pipe). The WARN_ON() calls become unnecessary and get removed. Finally, the return type is changed from __u16 to u16 because this is not a UAPI function. Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/r/20220317035514.6378-2-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 69aeb5073123 ("Input: pegasus-notetaker - fix potential out-of-bounds access") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c22cedbc18ddffe8e5bcb89518f9c9791170cb70 Author: Jiayuan Chen Date: Mon Nov 24 10:18:14 2025 -0500 mptcp: Disallow MPTCP subflows from sockmap [ Upstream commit fbade4bd08ba52cbc74a71c4e86e736f059f99f7 ] The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' Consider two scenarios: 1. When the server has MPTCP enabled and the client also requests MPTCP, the sk passed to the BPF program is a subflow sk. Since subflows only handle partial data, replacing their sk_prot is meaningless and will cause traffic disruption. 2. When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops() converts the subflow to plain TCP. For the first case, we should prevent it from being combined with sockmap by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by sockmap's own flow. For the second case, since subflow_syn_recv_sock() has already restored sk_prot to native tcp_prot/tcpv6_prot, no further action is needed. Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") Signed-off-by: Jiayuan Chen Signed-off-by: Martin KaFai Lau Reviewed-by: Matthieu Baerts (NGI0) Cc: Link: https://patch.msgid.link/20251111060307.194196-2-jiayuan.chen@linux.dev [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a4f32f3185aa70275f0da15d9cadac777e76c2e Author: Matthieu Baerts (NGI0) Date: Fri Nov 21 13:10:34 2025 -0500 selftests: mptcp: connect: fix fallback note due to OoO [ Upstream commit 63c643aa7b7287fdbb0167063785f89ece3f000f ] The "fallback due to TCP OoO" was never printed because the stat_ooo_now variable was checked twice: once in the parent if-statement, and one in the child one. The second condition was then always true then, and the 'else' branch was never taken. The idea is that when there are more ACK + MP_CAPABLE than expected, the test either fails if there was no out of order packets, or a notice is printed. Fixes: 69ca3d29a755 ("mptcp: update selftest for fallback due to OoO") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-1-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski [ Different operators used ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f3737fc3b8d90606a52df17c4e8be24d33c5bab7 Author: André Draszik Date: Fri Nov 21 12:16:26 2025 -0500 pmdomain: samsung: plug potential memleak during probe [ Upstream commit 90c82941adf1986364e0f82c35cf59f2bf5f6a1d ] of_genpd_add_provider_simple() could fail, in which case this code leaks the domain name, pd->pd.name. Use devm_kstrdup_const() to plug this leak. As a side-effect, we can simplify existing error handling. Fixes: c09a3e6c97f0 ("soc: samsung: pm_domains: Convert to regular platform driver") Cc: stable@vger.kernel.org Reviewed-by: Peter Griffin Reviewed-by: Krzysztof Kozlowski Signed-off-by: André Draszik Tested-by: Marek Szyprowski Signed-off-by: Ulf Hansson [ drivers/pmdomain/samsung/exynos-pm-domains.c -> drivers/soc/samsung/pm_domains.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 582f48d22eb5676fe7be3589b986ddd29f7bf4d1 Author: Sudeep Holla Date: Fri Nov 21 11:22:09 2025 -0500 pmdomain: arm: scmi: Fix genpd leak on provider registration failure [ Upstream commit 7458f72cc28f9eb0de811effcb5376d0ec19094a ] If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add(). Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure. Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20 Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd") Signed-off-by: Sudeep Holla Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson [ drivers/pmdomain/arm/scmi_pm_domain.c -> drivers/firmware/arm_scmi/scmi_pm_domain.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1d3f3d4c1faf8482477a1cbb0663e96794a18a23 Author: Miaoqian Lin Date: Fri Nov 21 11:22:06 2025 -0500 pmdomain: imx: Fix reference count leak in imx_gpc_remove [ Upstream commit bbde14682eba21d86f5f3d6fe2d371b1f97f1e61 ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add the missing of_node_put() to avoid refcount leak. Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Signed-off-by: Ulf Hansson [ drivers/pmdomain/imx/gpc.c -> drivers/soc/imx/gpc.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 890472d6fbf062e6de7fdd56642cb305ab79d669 Author: Breno Leitao Date: Thu Nov 20 20:52:15 2025 -0500 net: netpoll: fix incorrect refcount handling causing incorrect cleanup [ Upstream commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 ] commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: # 3.17.x Cc: Jay Vosburgh Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@debian.org Signed-off-by: Jakub Kicinski [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e9af27d1880a1f3acf9c9616a9ef1ec3895acc9d Author: Shawn Lin Date: Thu Nov 20 20:45:42 2025 -0500 mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4 [ Upstream commit a28352cf2d2f8380e7aca8cb61682396dca7a991 ] strbin signal delay under 0x8 configuration is not stable after massive test. The recommandation of it should be 0x4. Signed-off-by: Shawn Lin Tested-by: Alexey Charkov Tested-by: Hugh Cole-Baker Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e24a45da635bc97fcf4d931a3393ab4077a22e71 Author: Nathan Chancellor Date: Wed May 7 21:47:45 2025 +0100 net: qede: Initialize qede_ll_ops with designated initializer commit 6b3ab7f2cbfaeb6580709cd8ef4d72cfd01bfde4 upstream. After a recent change [1] in clang's randstruct implementation to randomize structures that only contain function pointers, there is an error because qede_ll_ops get randomized but does not use a designated initializer for the first member: drivers/net/ethernet/qlogic/qede/qede_main.c:206:2: error: a randomized struct can only be initialized with a designated initializer 206 | { | ^ Explicitly initialize the common member using a designated initializer to fix the build. Cc: stable@vger.kernel.org Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Link: https://github.com/llvm/llvm-project/commit/04364fb888eea6db9811510607bed4b200bcb082 [1] Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20250507-qede-fix-clang-randstruct-v1-1-5ccc15626fba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c993fd02ba471e296ca1996f13626fc917120158 Author: Omar Sandoval Date: Fri May 24 13:58:11 2024 -0700 btrfs: fix crash on racing fsync and size-extending write into prealloc commit 9d274c19a71b3a276949933859610721a453946b upstream. We have been seeing crashes on duplicate keys in btrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121) So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG(). This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ... So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and item 5 starts at i_size. Here is the state of the filesystem tree at the time of the crash: >>> root = prog.crashed_thread().stack_trace()[2]["inode"].root >>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0)) >>> print_extent_buffer(nodes[0]) leaf 30425088 level 0 items 184 generation 9 owner 5 leaf 30425088 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da ... item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160 generation 7 transid 7 size 4096 nbytes 12288 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 6 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417703.220000000 (2024-05-22 15:41:43) mtime 1716417703.220000000 (2024-05-22 15:41:43) otime 1716417703.220000000 (2024-05-22 15:41:43) item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13 index 195 namelen 3 name: 193 item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 8192 ram 12288 extent compression 0 (none) item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 Item 5 in the log tree corresponds to item 183 in the filesystem tree, but nothing matches item 4. Furthermore, item 183 is the last item in the leaf. btrfs_log_prealloc_extents() is responsible for logging prealloc extents beyond i_size. It first truncates any previously logged prealloc extents that start beyond i_size. Then, it walks the filesystem tree and copies the prealloc extent items to the log tree. If it hits the end of a leaf, then it calls btrfs_next_leaf(), which unlocks the tree and does another search. However, while the filesystem tree is unlocked, an ordered extent completion may modify the tree. In particular, it may insert an extent item that overlaps with an extent item that was already copied to the log tree. This may manifest in several ways depending on the exact scenario, including an EEXIST error that is silently translated to a full sync, overlapping items in the log tree, or this crash. This particular crash is triggered by the following sequence of events: - Initially, the file has i_size=4k, a regular extent from 0-4k, and a prealloc extent beyond i_size from 4k-12k. The prealloc extent item is the last item in its B-tree leaf. - The file is fsync'd, which copies its inode item and both extent items to the log tree. - An xattr is set on the file, which sets the BTRFS_INODE_COPY_EVERYTHING flag. - The range 4k-8k in the file is written using direct I/O. i_size is extended to 8k, but the ordered extent is still in flight. - The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this calls copy_inode_items_to_log(), which calls btrfs_log_prealloc_extents(). - btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the filesystem tree. Since it starts before i_size, it skips it. Since it is the last item in its B-tree leaf, it calls btrfs_next_leaf(). - btrfs_next_leaf() unlocks the path. - The ordered extent completion runs, which converts the 4k-8k part of the prealloc extent to written and inserts the remaining prealloc part from 8k-12k. - btrfs_next_leaf() does a search and finds the new prealloc extent 8k-12k. - btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into the log tree. Note that it overlaps with the 4k-12k prealloc extent that was copied to the log tree by the first fsync. - fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k extent that was written. - This tries to drop the range 4k-8k in the log tree, which requires adjusting the start of the 4k-12k prealloc extent in the log tree to 8k. - btrfs_set_item_key_safe() sees that there is already an extent starting at 8k in the log tree and calls BUG(). Fix this by detecting when we're about to insert an overlapping file extent item in the log tree and truncating the part that would overlap. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana Signed-off-by: Omar Sandoval Signed-off-by: David Sterba Signed-off-by: Harshvardhan Jha Signed-off-by: Greg Kroah-Hartman commit bff4d06c38a7b71f469e9681b1f1ddd6824799f7 Author: Filipe Manana Date: Tue Aug 31 15:30:36 2021 +0100 btrfs: add helper to truncate inode items when logging inode commit 8a2b3da191e5a167bba9776e109b775b21cb4d85 upstream. Move the call to btrfs_truncate_inode_items(), and the surrounding retry loop, into a local helper function. This avoids some repetition and avoids making the next change a bit awkward due to a bit of too much indentation. This patch is part of a patch set comprised of the following patches: btrfs: check if a log tree exists at inode_logged() btrfs: remove no longer needed checks for NULL log context btrfs: do not log new dentries when logging that a new name exists btrfs: always update the logged transaction when logging new names btrfs: avoid expensive search when dropping inode items from log btrfs: add helper to truncate inode items when logging inode btrfs: avoid expensive search when truncating inode items from the log btrfs: avoid search for logged i_size when logging inode if possible btrfs: avoid attempt to drop extents when logging inode for the first time btrfs: do not commit delayed inode when logging a file in full sync mode This is patch 6/10 and test results are listed in the change log of the last patch in the set. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Harshvardhan Jha Signed-off-by: Greg Kroah-Hartman commit 707d49dd441ab9c0e287cb49942db4e91988786b Author: Nick Desaulniers Date: Mon Sep 19 10:08:28 2022 -0700 Makefile.compiler: replace cc-ifversion with compiler-specific macros commit 88b61e3bff93f99712718db785b4aa0c1165f35c upstream. cc-ifversion is GCC specific. Replace it with compiler specific variants. Update the users of cc-ifversion to use these new macros. Link: https://github.com/ClangBuiltLinux/linux/issues/350 Link: https://lore.kernel.org/llvm/CAGG=3QWSAUakO42kubrCap8fp-gm1ERJJAYXTnP1iHk_wrH=BQ@mail.gmail.com/ Suggested-by: Bill Wendling Reviewed-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada [nathan: Backport to 5.15 and eliminate instances of cc-ifversion that did not exist upstream when this change was original created] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 4c019e93f0e54e25888856de51467a35f7648b00 Author: Long Li Date: Mon Mar 10 15:12:01 2025 -0700 uio_hv_generic: Set event for all channels on the device commit d062463edf1770427dc2d637df4088df4835aa47 upstream. Hyper-V may offer a non latency sensitive device with subchannels without monitor bit enabled. The decision is entirely on the Hyper-V host not configurable within guest. When a device has subchannels, also signal events for the subchannel if its monitor bit is disabled. This patch also removes the memory barrier when monitor bit is enabled as it is not necessary. The memory barrier is only needed between setting up interrupt mask and calling vmbus_set_event() when monitor bit is disabled. Signed-off-by: Long Li Reviewed-by: Michael Kelley Reviewed-by: Saurabh Sengar Link: https://lore.kernel.org/r/1741644721-20389-1-git-send-email-longli@linuxonhyperv.com Fixes: b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask") Closes: https://bugs.debian.org/1120602 Signed-off-by: Naman Jain Signed-off-by: Greg Kroah-Hartman commit 80fe72069168ec3f7f041f3dafe7ea40ed50ad2f Author: Zhang Chujun Date: Thu Nov 6 11:10:40 2025 +0800 tracing/tools: Fix incorrcet short option in usage text for --threads [ Upstream commit 53afec2c8fb2a562222948cb1c2aac48598578c9 ] The help message incorrectly listed '-t' as the short option for --threads, but the actual getopt_long configuration uses '-e'. This mismatch can confuse users and lead to incorrect command-line usage. This patch updates the usage string to correctly show: "-e, --threads NRTHR" to match the implementation. Note: checkpatch.pl reports a false-positive spelling warning on 'Run', which is intentional. Link: https://patch.msgid.link/20251106031040.1869-1-zhangchujun@cmss.chinamobile.com Signed-off-by: Zhang Chujun Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 3afeb909c3e2e0eb19b1e20506196e5f2d9c2259 Author: Nishanth Menon Date: Mon Nov 3 10:28:11 2025 -0600 net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error [ Upstream commit 90a88306eb874fe4bbdd860e6c9787f5bbc588b5 ] Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcp_core: return error while dma channel open issue"), but provides a less error prone implementation. Suggested-by: Simon Horman Suggested-by: Jacob Keller Signed-off-by: Nishanth Menon Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20251103162811.3730055-1-nm@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75ccdb4afe41ccaf9f83c05442a39fb3f82592e8 Author: René Rebe Date: Tue Nov 25 15:41:49 2025 +0100 ALSA: usb-audio: fix uac2 clock source at terminal parser [ Upstream commit d26e9f669cc0a6a85cf17180c09a6686db9f4002 ] Since 8b3a087f7f65 ("ALSA: usb-audio: Unify virtual type units type to UAC3 values") usb-audio is using UAC3_CLOCK_SOURCE instead of bDescriptorSubtype, later refactored with e0ccdef9265 ("ALSA: usb-audio: Clean up check_input_term()") into parse_term_uac2_clock_source(). This breaks the clock source selection for at least my 1397:0003 BEHRINGER International GmbH FCA610 Pro. Fix by using UAC2_CLOCK_SOURCE in parse_term_uac2_clock_source(). Fixes: 8b3a087f7f65 ("ALSA: usb-audio: Unify virtual type units type to UAC3 values") Signed-off-by: René Rebe Link: https://patch.msgid.link/20251125.154149.1121389544970412061.rene@exactco.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bb1c19636aedae39360e6fdbcaef4f2bcff25785 Author: Lance Yang Date: Thu Nov 20 21:38:21 2025 +0200 mm/secretmem: fix use-after-free race in fault handler [ Upstream commit 6f86d0534fddfbd08687fa0f01479d4226bc3c3d ] When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new page for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a page and removing the page from the direct map, but only one would succeed in adding the page to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the page again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the page is freed. Link: https://lkml.kernel.org/r/20251031120955.92116-1-lance.yang@linux.dev Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lance Yang Reported-by: Google Big Sleep Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWKrdQJ-ATdg@mail.gmail.com/ Acked-by: David Hildenbrand Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton (cherry picked from commit 6f86d0534fddfbd08687fa0f01479d4226bc3c3d) [rppt: replaced folio with page in the patch and in the changelog] Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 2ef178413183c09d91b76d12a7611dbe10153681 Author: Isaac J. Manjarres Date: Thu Nov 20 21:36:25 2025 +0200 mm/mm_init: fix hash table order logging in alloc_large_system_hash() [ Upstream commit 0d6c356dd6547adac2b06b461528e3573f52d953 ] When emitting the order of the allocation for a hash table, alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log base 2 of the allocation size. This is not correct if the allocation size is smaller than a page, and yields a negative value for the order as seen below: TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP bind hash table entries: 32 (order: -2, 1024 bytes, linear) Use get_order() to compute the order when emitting the hash table information to correctly handle cases where the allocation size is smaller than a page: TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP bind hash table entries: 32 (order: 0, 1024 bytes, linear) Link: https://lkml.kernel.org/r/20251028191020.413002-1-isaacmanjarres@google.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Isaac J. Manjarres Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: David Hildenbrand Cc: Signed-off-by: Andrew Morton (cherry picked from commit 0d6c356dd6547adac2b06b461528e3573f52d953) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit dcf80cb1bf88f394d4f7df766b1345a29bae145a Author: Jakub Horký Date: Tue Oct 14 16:44:06 2025 +0200 kconfig/nconf: Initialize the default locale at startup [ Upstream commit 43c2931a95e6b295bfe9e3b90dbe0f7596933e91 ] Fix bug where make nconfig doesn't initialize the default locale, which causes ncurses menu borders to be displayed incorrectly (lqqqqk) in UTF-8 terminals that don't support VT100 ACS by default, such as PuTTY. Signed-off-by: Jakub Horký Link: https://patch.msgid.link/20251014144405.3975275-2-jakub.git@horky.net [nathan: Alphabetize locale.h include] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 87297ab1e7833e3da175599c55c068dc25ff6753 Author: Jakub Horký Date: Tue Oct 14 17:49:32 2025 +0200 kconfig/mconf: Initialize the default locale at startup [ Upstream commit 3927c4a1084c48ef97f11281a0a43ecb2cb4d6f1 ] Fix bug where make menuconfig doesn't initialize the default locale, which causes ncurses menu borders to be displayed incorrectly (lqqqqk) in UTF-8 terminals that don't support VT100 ACS by default, such as PuTTY. Signed-off-by: Jakub Horký Link: https://patch.msgid.link/20251014154933.3990990-1-jakub.git@horky.net [nathan: Alphabetize locale.h include] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 699c6cc0f18e294e5adeb687da755e28ec75a04a Author: Shahar Shitrit Date: Sun Oct 26 22:03:02 2025 +0200 net: tls: Cancel RX async resync request on rcd_delta overflow [ Upstream commit c15d5c62ab313c19121f10e25d4fec852bd1c40c ] When a netdev issues a RX async resync request for a TLS connection, the TLS module handles it by logging record headers and attempting to match them to the tcp_sn provided by the device. If a match is found, the TLS module approves the tcp_sn for resynchronization. While waiting for a device response, the TLS module also increments rcd_delta each time a new TLS record is received, tracking the distance from the original resync request. However, if the device response is delayed or fails (e.g due to unstable connection and device getting out of tracking, hardware errors, resource exhaustion etc.), the TLS module keeps logging and incrementing, which can lead to a WARN() when rcd_delta exceeds the threshold. To address this, introduce tls_offload_rx_resync_async_request_cancel() to explicitly cancel resync requests when a device response failure is detected. Call this helper also as a final safeguard when rcd_delta crosses its threshold, as reaching this point implies that earlier cancellation did not occur. Signed-off-by: Shahar Shitrit Reviewed-by: Sabrina Dubroca Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1761508983-937977-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbbcd769c8003723cf31609c8db1771076ff74d5 Author: Po-Hsu Lin Date: Mon Oct 27 17:57:10 2025 +0800 selftests: net: use BASH for bareudp testing [ Upstream commit 9311e9540a8b406d9f028aa87fb072a3819d4c82 ] In bareudp.sh, this script uses /bin/sh and it will load another lib.sh BASH script at the very beginning. But on some operating systems like Ubuntu, /bin/sh is actually pointed to DASH, thus it will try to run BASH commands with DASH and consequently leads to syntax issues: # ./bareudp.sh: 4: ./lib.sh: Bad substitution # ./bareudp.sh: 5: ./lib.sh: source: not found # ./bareudp.sh: 24: ./lib.sh: Syntax error: "(" unexpected Fix this by explicitly using BASH for bareudp.sh. This fixes test execution failures on systems where /bin/sh is not BASH. Reported-by: Edoardo Canepa Link: https://bugs.launchpad.net/bugs/2129812 Signed-off-by: Po-Hsu Lin Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/20251027095710.2036108-2-po-hsu.lin@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 804b5b8e3545445450387ae6891262c421c49304 Author: Bart Van Assche Date: Tue Oct 7 14:48:00 2025 -0700 scsi: core: Fix a regression triggered by scsi_host_busy() [ Upstream commit a0b7780602b1b196f47e527fec82166a7e67c4d0 ] Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag iterators") introduced the following regression: Call trace: __srcu_read_lock+0x30/0x80 (P) blk_mq_tagset_busy_iter+0x44/0x300 scsi_host_busy+0x38/0x70 ufshcd_print_host_state+0x34/0x1bc ufshcd_link_startup.constprop.0+0xe4/0x2e0 ufshcd_init+0x944/0xf80 ufshcd_pltfrm_init+0x504/0x820 ufs_rockchip_probe+0x2c/0x88 platform_probe+0x5c/0xa4 really_probe+0xc0/0x38c __driver_probe_device+0x7c/0x150 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1e0 bus_for_each_dev+0x7c/0xdc driver_attach+0x24/0x30 bus_add_driver+0x110/0x230 driver_register+0x68/0x130 __platform_driver_register+0x20/0x2c ufs_rockchip_pltform_init+0x1c/0x28 do_one_initcall+0x60/0x1e0 kernel_init_freeable+0x248/0x2c4 kernel_init+0x20/0x140 ret_from_fork+0x10/0x20 Fix this regression by making scsi_host_busy() check whether the SCSI host tag set has already been initialized. tag_set->ops is set by scsi_mq_setup_tags() just before blk_mq_alloc_tag_set() is called. This fix is based on the assumption that scsi_host_busy() and scsi_mq_setup_tags() calls are serialized. This is the case in the UFS driver. Reported-by: Sebastian Reichel Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/ Cc: Ming Lei Cc: Jens Axboe Signed-off-by: Bart Van Assche Reviewed-by: Ming Lei Tested-by: Sebastian Reichel Link: https://patch.msgid.link/20251007214800.1678255-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 67432915145848658149683101104e32f9fd6559 Author: Michal Luczaj Date: Wed Nov 19 15:02:59 2025 +0100 vsock: Ignore signal/timeout on connect() if already established [ Upstream commit 002541ef650b742a198e4be363881439bb9d86b4 ] During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/ Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20251119-vsock-interrupted-connect-v2-1-70734cf1233f@rbox.co Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecbb12caf399d7cf364b7553ed5aebeaa2f255bc Author: Pavel Zhigulin Date: Thu Nov 13 14:27:56 2025 +0300 net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() [ Upstream commit 896f1a2493b59beb2b5ccdf990503dbb16cb2256 ] The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 55482edc25f0 ("qede: Add slowpath/fastpath support and enable hardware GRO") Signed-off-by: Pavel Zhigulin Link: https://patch.msgid.link/20251113112757.4166625-1-Pavel.Zhigulin@kaspersky.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 597bbbe023d97428fcfac827bd2ebc349fec59de Author: Alejandro Colomar Date: Tue Oct 3 14:59:53 2023 +0300 kernel.h: Move ARRAY_SIZE() to a separate header [ Upstream commit 3cd39bc3b11b8d34b7d7c961a35fdfd18b0ebf75 ] Touching files so used for the kernel, forces 'make' to recompile most of the kernel. Having those definitions in more granular files helps avoid recompiling so much of the kernel. Signed-off-by: Alejandro Colomar Reviewed-by: Giovanni Cabiddu Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230817143352.132583-2-lucas.segarra.fernandez@intel.com [andy: reduced to cover only string.h for now] Signed-off-by: Andy Shevchenko Stable-dep-of: 896f1a2493b5 ("net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()") Signed-off-by: Sasha Levin commit ca4452aa69ab9a265040720f0ef61764a44e960c Author: Haotian Zhang Date: Mon Nov 17 11:33:54 2025 +0800 platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to errnos [ Upstream commit d8bb447efc5622577994287dc77c684fa8840b30 ] isst_if_probe() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is returned from the probe function as is but probe functions should return normal errnos. A proper implementation can be found in drivers/leds/leds-ss4200.c. Convert PCIBIOS_* return codes using pcibios_err_to_errno() into normal errno before returning. Fixes: d3a23584294c ("platform/x86: ISST: Add Intel Speed Select mmio interface") Signed-off-by: Haotian Zhang Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20251117033354.132-1-vulab@iscas.ac.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7616e2eee679746d526c7f5befd4eedb995935b5 Author: Aleksei Nikiforov Date: Wed Nov 12 19:27:24 2025 +0100 s390/ctcm: Fix double-kfree [ Upstream commit da02a1824884d6c84c5e5b5ac373b0c9e3288ec2 ] The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer. Fixes: 0c0b20587b9f25a2 ("s390/ctcm: fix potential memory leak") Reviewed-by: Aswin Karuvally Signed-off-by: Aleksei Nikiforov Signed-off-by: Aswin Karuvally Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251112182724.1109474-1-aswin@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f95bef5ba0b88d971b02c776f24bd17544930a3a Author: Ilya Maximets Date: Wed Nov 12 12:14:03 2025 +0100 net: openvswitch: remove never-working support for setting nsh fields [ Upstream commit dfe28c4167a9259fc0c372d9f9473e1ac95cff67 ] The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases. Fixes: b2d0f5d5dc53 ("openvswitch: enable NSH support") Reported-by: Junvy Yang Signed-off-by: Ilya Maximets Acked-by: Eelco Chaudron Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20251112112246.95064-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20d7e6bce8e21b2b6c84a403d85dd8b8e646d544 Author: Pavel Zhigulin Date: Thu Nov 13 16:57:44 2025 +0300 net: dsa: hellcreek: fix missing error handling in LED registration [ Upstream commit e6751b0b19a6baab219a62e1e302b8aa6b5a55b2 ] The LED setup routine registered both led_sync_good and led_is_gm devices without checking the return values of led_classdev_register(). If either registration failed, the function continued silently, leaving the driver in a partially-initialized state and leaking a registered LED classdev. Add proper error handling Fixes: 7d9ee2e8ff15 ("net: dsa: hellcreek: Add PTP status LEDs") Signed-off-by: Pavel Zhigulin Reviewed-by: Andrew Lunn Acked-by: Kurt Kanzenbach Link: https://patch.msgid.link/20251113135745.92375-1-Pavel.Zhigulin@kaspersky.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba8d3df04c00d5aedc5ddcdfaba17239928a082c Author: Zilin Guan Date: Wed Nov 12 05:21:14 2025 +0000 mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats() [ Upstream commit 407a06507c2358554958e8164dc97176feddcafc ] The function mlxsw_sp_flower_stats() calls mlxsw_sp_acl_ruleset_get() to obtain a ruleset reference. If the subsequent call to mlxsw_sp_acl_rule_lookup() fails to find a rule, the function returns an error without releasing the ruleset reference, causing a memory leak. Fix this by using a goto to the existing error handling label, which calls mlxsw_sp_acl_ruleset_put() to properly release the reference. Fixes: 7c1b8eb175b69 ("mlxsw: spectrum: Add support for TC flower offload statistics") Signed-off-by: Zilin Guan Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20251112052114.1591695-1-zilin@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fb232c763341ceeba5a67c65cbff200ace820a9 Author: Ma Ke Date: Wed Oct 22 19:47:20 2025 +0800 drm/tegra: dc: Fix reference leak in tegra_dc_couple() commit 4c5376b4b143c4834ebd392aef2215847752b16a upstream. driver_find_device() calls get_device() to increment the reference count once a matching device is found, but there is no put_device() to balance the reference count. To avoid reference count leakage, add put_device() to decrease the reference count. Found by code review. Cc: stable@vger.kernel.org Fixes: a31500fe7055 ("drm/tegra: dc: Restore coupling of display controllers") Signed-off-by: Ma Ke Acked-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20251022114720.24937-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 99908e2d601236842d705d5fd04fb349577316f5 Author: Eric Dumazet Date: Thu Nov 13 10:39:24 2025 +0000 mptcp: fix race condition in mptcp_schedule_work() commit 035bca3f017ee9dea3a5a756e77a6f7138cc6eea upstream. syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Cc: stable@vger.kernel.org Fixes: 3b1d6210a957 ("mptcp: implement and use MPTCP-level retransmission") Reported-by: syzbot+355158e7e301548a1424@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6915b46f.050a0220.3565dc.0028.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251113103924.3737425-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7536472a4575e8a76ec6415a0a7ed8ea8068301d Author: Maciej W. Rozycki Date: Mon Oct 20 02:11:49 2025 +0100 MIPS: Malta: Fix !EVA SOC-it PCI MMIO commit ebd729fef31620e0bf74cbf8a4c7fda73a2a4e7e upstream. Fix a regression that has caused accesses to the PCI MMIO window to complete unclaimed in non-EVA configurations with the SOC-it family of system controllers, preventing PCI devices from working that use MMIO. In the non-EVA case PHYS_OFFSET is set to 0, meaning that PCI_BAR0 is set with an empty mask (and PCI_HEAD4 matches addresses starting from 0 accordingly). Consequently all addresses are matched for incoming DMA accesses from PCI. This seems to confuse the system controller's logic and outgoing bus cycles targeting the PCI MMIO window seem not to make it to the intended devices. This happens as well when a wider mask is used with PCI_BAR0, such as 0x80000000 or 0xe0000000, that makes addresses match that overlap with the PCI MMIO window, which starts at 0x10000000 in our configuration. Set the mask in PCI_BAR0 to 0xf0000000 for non-EVA then, covering the non-EVA maximum 256 MiB of RAM, which is what YAMON does and which used to work correctly up to the offending commit. Set PCI_P2SCMSKL to match PCI_BAR0 as required by the system controller's specification, and match PCI_P2SCMAPL to PCI_HEAD4 for identity mapping. Verified with: Core board type/revision = 0x0d (Core74K) / 0x01 System controller/revision = MIPS SOC-it 101 OCP / 1.3 SDR-FW-4:1 Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x1c Processor ID/revision = 0x97 (MIPS 74Kf) / 0x4c for non-EVA and with: Core board type/revision = 0x0c (CoreFPGA-5) / 0x00 System controller/revision = MIPS ROC-it2 / 0.0 FW-1:1 (CLK_unknown) GIC Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x00 Processor ID/revision = 0xa0 (MIPS interAptiv UP) / 0x20 for EVA/non-EVA, fixing: defxx 0000:00:12.0: assign IRQ: got 10 defxx: v1.12 2021/03/10 Lawrence V. Stefani and others 0000:00:12.0: Could not read adapter factory MAC address! vs: defxx 0000:00:12.0: assign IRQ: got 10 defxx: v1.12 2021/03/10 Lawrence V. Stefani and others 0000:00:12.0: DEFPA at MMIO addr = 0x10142000, IRQ = 10, Hardware addr = 00-00-f8-xx-xx-xx 0000:00:12.0: registered as fddi0 for non-EVA and causing no change for EVA. Signed-off-by: Maciej W. Rozycki Fixes: 422dd256642b ("MIPS: Malta: Allow PCI devices DMA to lower 2GB physical") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit f449a1edd7a13bb025aaf9342ea6f8bf92684bbf Author: Hamza Mahfooz Date: Wed Nov 5 11:25:46 2025 -0800 scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc upstream. If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable@vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz Reviewed-by: Chaitanya Kulkarni Reviewed-by: Allen Pais Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linux.microsoft.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 109afbd88ecc46b6cc7551367222387e97999765 Author: Bart Van Assche Date: Thu Nov 13 10:16:43 2025 -0800 scsi: sg: Do not sleep in atomic context commit 90449f2d1e1f020835cba5417234636937dd657e upstream. sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled. Reported-by: syzbot+c01f8e6e73f20459912e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google.com/ Cc: Hannes Reinecke Cc: stable@vger.kernel.org Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 60ba31330faf5677e2eebef7eac62ea9e42a200d Author: Ewan D. Milne Date: Mon Nov 10 16:20:01 2025 -0500 nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() commit 0a2c5495b6d1ecb0fa18ef6631450f391a888256 upstream. nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] Fixes: 19fce0470f05 ("nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context") Cc: stable@vger.kernel.org Tested-by: Marco Patalano Reviewed-by: Justin Tee Signed-off-by: Ewan D. Milne Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 4ce5218b101205b3425099fe3df88a61b58f9cc2 Author: Dan Carpenter Date: Sat Nov 1 16:25:27 2025 +0300 Input: imx_sc_key - fix memory corruption on unload commit d83f1512758f4ef6fc5e83219fe7eeeb6b428ea4 upstream. This is supposed to be "priv" but we accidentally pass "&priv" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &. Fixes: 768062fd1284 ("Input: imx_sc_key - use devm_add_action_or_reset() to handle all cleanups") Signed-off-by: Dan Carpenter Reviewed-by: Peng Fan Reviewed-by: Frank Li Link: https://patch.msgid.link/aQYKR75r2VMFJutT@stanley.mountain Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 729d21c82c1b0504ffccb17cc261bf32e024fd0f Author: Tzung-Bi Shih Date: Tue Nov 4 07:03:10 2025 +0000 Input: cros_ec_keyb - fix an invalid memory access commit e08969c4d65ac31297fcb4d31d4808c789152f68 upstream. If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them. Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20251104070310.3212712-1-tzungbi@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 630360c6724e27f1aa494ba3fffe1e38c4205284 Author: Andrey Vatoropin Date: Wed Nov 19 10:51:12 2025 +0000 be2net: pass wrb_params in case of OS2BMC commit 7d277a7a58578dd62fd546ddaef459ec24ccae36 upstream. be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states. The correct way would be to pass the wrb_params from be_xmit(). Fixes: 760c295e0e8d ("be2net: Support for OS2BMC.") Cc: stable@vger.kernel.org Signed-off-by: Andrey Vatoropin Link: https://patch.msgid.link/20251119105015.194501-1-a.vatoropin@crpt.ru Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f2e52a9d10d86d02954eeb95db61fbacae543ab8 Author: Yongpeng Yang Date: Tue Nov 4 20:50:07 2025 +0800 exfat: check return value of sb_min_blocksize in exfat_read_boot_sector commit f2c1f631630e01821fe4c3fdf6077bc7a8284f82 upstream. sb_min_blocksize() may return 0. Check its return value to avoid accessing the filesystem super block when sb->s_blocksize is 0. Cc: stable@vger.kernel.org # v6.15 Fixes: 719c1e1829166d ("exfat: add super block operations") Reviewed-by: Christoph Hellwig Signed-off-by: Yongpeng Yang Link: https://patch.msgid.link/20251104125009.2111925-3-yangyongpeng.storage@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 9c58c64ec41290c12490ca7e1df45013fbbb41fd Author: Niravkumar L Rabara Date: Thu Oct 23 11:32:01 2025 +0800 mtd: rawnand: cadence: fix DMA device NULL pointer dereference commit 5c56bf214af85ca042bf97f8584aab2151035840 upstream. The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use. Fixes: d76d22b5096c ("mtd: rawnand: cadence: use dma_map_resource for sdma address") Cc: stable@vger.kernel.org Signed-off-by: Niravkumar L Rabara Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit de9dc8cbeea0c459eda5b5a7a5e572a3a30058cc Author: Zhang Heng Date: Fri Sep 12 20:38:18 2025 +0800 HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155 commit beab067dbcff642243291fd528355d64c41dc3b2 upstream. Based on available evidence, the USB ID 4c4a:4155 used by multiple devices has been attributed to Jieli. The commit 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") affected touchscreen functionality. Added checks for manufacturer and serial number to maintain microphone compatibility, enabling both devices to function properly. [jkosina@suse.com: edit shortlog] Fixes: 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") Cc: stable@vger.kernel.org Tested-by: staffan.melin@oscillator.se Reviewed-by: Terry Junge Signed-off-by: Zhang Heng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 652b24f07bae56e3e690b7f6516c238481376b59 Author: Pedro Tammela Date: Mon Feb 27 12:23:52 2023 -0300 net/sched: act_connmark: handle errno on tcf_idr_check_alloc commit fb07390463c95e6eef254044d6dde050bfb9807a upstream. Smatch reports that 'ci' can be used uninitialized. The current code ignores errno coming from tcf_idr_check_alloc, which will lead to the incorrect usage of 'ci'. Handle the errno as it should. Fixes: 288864effe33 ("net/sched: act_connmark: transition to percpu stats and rcu") Reviewed-by: Jamal Hadi Salim Signed-off-by: Pedro Tammela Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b70c24827e11fdc71465f9207e974526fb457bb9 Author: Abdun Nihaal Date: Thu Oct 30 09:55:22 2025 +0530 isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() commit 3f978e3f1570155a1327ffa25f60968bc7b9398f upstream. In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool. Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20251030042524.194812-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bf51f26c5bcca83f49816376cb077ee42135d235 Author: Niravkumar L Rabara Date: Tue Nov 11 16:13:33 2025 +0800 EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection commit 281326be67252ac5794d1383f67526606b1d6b13 upstream. The current single-bit error injection mechanism flips bits directly in ECC RAM by performing write and read operations. When the ECC RAM is actively used by the Ethernet or USB controller, this approach sometimes trigger a false double-bit error. Switch both Ethernet and USB EDAC devices to use the INTTEST register (altr_edac_a10_device_inject_fops) for single-bit error injection, similar to the existing double-bit error injection method. Fixes: 064acbd4f4ab ("EDAC, altera: Add Stratix10 peripheral support") Signed-off-by: Niravkumar L Rabara Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251111081333.1279635-1-niravkumarlaxmidas.rabara@altera.com Signed-off-by: Greg Kroah-Hartman commit 76eb3ac2f01a3041a3f18bc50e188021d96f97b0 Author: Niravkumar L Rabara Date: Tue Nov 11 16:08:01 2025 +0800 EDAC/altera: Handle OCRAM ECC enable after warm reset commit fd3ecda38fe0cb713d167b5477d25f6b350f0514 upstream. The OCRAM ECC is always enabled either by the BootROM or by the Secure Device Manager (SDM) during a power-on reset on SoCFPGA. However, during a warm reset, the OCRAM content is retained to preserve data, while the control and status registers are reset to their default values. As a result, ECC must be explicitly re-enabled after a warm reset. Fixes: 17e47dc6db4f ("EDAC/altera: Add Stratix10 OCRAM ECC support") Signed-off-by: Niravkumar L Rabara Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251111080801.1279401-1-niravkumarlaxmidas.rabara@altera.com Signed-off-by: Greg Kroah-Hartman commit 4b63d3858a1e1ea15f05a2283af602725639a2d1 Author: Hans de Goede Date: Sun Nov 2 20:09:21 2025 +0100 spi: Try to get ACPI GPIO IRQ earlier commit 3cd2018e15b3d66d2187d92867e265f45ad79e6f upstream. Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device. If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables. Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet. Link: https://bbs.archlinux.org/viewtopic.php?id=302348 Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20251102190921.30068-1-hansg@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8af069dc2fbf848216f28da23d4691dde8ba2164 Author: Takashi Iwai Date: Wed Nov 26 11:08:31 2025 +0100 ALSA: usb-audio: Fix missing unlock at error path of maxpacksize check commit fdf0dc82eb60091772ecea73cbc5a8fb7562fc45 upstream. The recent backport of the upstream commit 05a1fc5efdd8 ("ALSA: usb-audio: Fix potential overflow of PCM transfer buffer") on the older stable kernels like 6.12.y was broken since it doesn't consider the mutex unlock, where the upstream code manages with guard(). In the older code, we still need an explicit unlock. This is a fix that corrects the error path, applied only on old stable trees. Reported-by: Pavel Machek Closes: https://lore.kernel.org/aSWtH0AZH5+aeb+a@duo.ucw.cz Fixes: 98e9d5e33bda ("ALSA: usb-audio: Fix potential overflow of PCM transfer buffer") Reviewed-by: Pavel Machek Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 217d47255a2ec8b246f2725f5db9ac3f1d4109d7 Author: Takashi Iwai Date: Sun Nov 9 10:12:07 2025 +0100 ALSA: usb-audio: Fix potential overflow of PCM transfer buffer commit 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf upstream. The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0]. Reported-by: syzbot+bfd77469c8966de076f7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bfd77469c8966de076f7 Link: https://lore.kernel.org/690b6b46.050a0220.3d0d33.0054.GAE@google.com Cc: Lizhi Xu Cc: Link: https://patch.msgid.link/20251109091211.12739-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4cba73c4c89219beef7685a47374bf88b1022369 Author: Wei Yang Date: Sat Oct 25 10:42:33 2025 +0800 fs/proc: fix uaf in proc_readdir_de() commit 895b4c0c79b092d732544011c3cecaf7322c36a1 upstream. Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2) Link: https://lkml.kernel.org/r/20251025024233.158363-1-albin_yang@163.com Signed-off-by: Wei Yang Cc: Al Viro Cc: Christian Brauner Cc: wangzijie Cc: Alexey Dobriyan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 298f1e0694ab4edb6092d66efed93c4554e6ced1 Author: Chuang Wang Date: Tue Nov 11 14:43:24 2025 +0800 ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe commit ac1499fcd40fe06479e9b933347b837ccabc2a40 upstream. The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1 Cc: stable@vger.kernel.org Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible") Signed-off-by: Chuang Wang Reviewed-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20251111064328.24440-1-nashuiliang@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5fb4722507b74018a99729253bb2231f54021ecd Author: Nate Karstens Date: Thu Nov 6 16:28:33 2025 -0600 strparser: Fix signed/unsigned mismatch bug commit 4da4e4bde1c453ac5cc2dce5def81d504ae257ee upstream. The `len` member of the sk_buff is an unsigned int. This is cast to `ssize_t` (a signed type) for the first sk_buff in the comparison, but not the second sk_buff. On 32-bit systems, this can result in an integer underflow for certain values because unsigned arithmetic is being used. This appears to be an oversight: if the intention was to use unsigned arithmetic, then the first cast would have been omitted. The change ensures both len values are cast to `ssize_t`. The underflow causes an issue with ktls when multiple TLS PDUs are included in a single TCP segment. The mainline kernel does not use strparser for ktls anymore, but this is still useful for other features that still use strparser, and for backporting. Signed-off-by: Nate Karstens Cc: stable@vger.kernel.org Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") Reviewed-by: Jacob Keller Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20251106222835.1871628-1-nate.karstens@garmin.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3b9447e6877717e6a89eb9373dc9b087427e7365 Author: Peter Oberparleiter Date: Tue Oct 28 12:51:25 2025 +0100 gcov: add support for GCC 15 commit ec4d11fc4b2dd4a2fa8c9d801ee9753b74623554 upstream. Using gcov on kernels compiled with GCC 15 results in truncated 16-byte long .gcda files with no usable data. To fix this, update GCOV_COUNTERS to match the value defined by GCC 15. Tested with GCC 14.3.0 and GCC 15.2.0. Link: https://lkml.kernel.org/r/20251028115125.1319410-1-oberpar@linux.ibm.com Signed-off-by: Peter Oberparleiter Reported-by: Matthieu Baerts Closes: https://github.com/linux-test-project/lcov/issues/445 Tested-by: Matthieu Baerts Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b114996a095da39e38410a0328d4a8aca8c36088 Author: Olga Kornievskaia Date: Tue Oct 14 13:59:59 2025 -0400 NFSD: free copynotify stateid in nfs4_free_ol_stateid() commit 4aa17144d5abc3c756883e3a010246f0dba8b468 upstream. Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs Reported-by: rtm@csail.mit.edu Closes: https://lore.kernel.org/linux-nfs/d8f064c1-a26f-4eed-b4f0-1f7f608f415f@oracle.com/T/#t Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit d0ee0b42a9c00fb0bee0c6c9a00ea105b0fc473c Author: Masami Ichikawa Date: Sun Sep 21 14:31:02 2025 +0900 HID: hid-ntrig: Prevent memory leak in ntrig_report_version() [ Upstream commit 53f731f5bba0cf03b751ccceb98b82fadc9ccd1e ] Use a scope-based cleanup helper for the buffer allocated with kmalloc() in ntrig_report_version() to simplify the cleanup logic and prevent memory leaks (specifically the !hid_is_usb()-case one). [jkosina@suse.com: elaborate on the actual existing leak] Fixes: 185c926283da ("HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()") Signed-off-by: Masami Ichikawa Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 4681960bc0f4f8bcc782cbf2fd205f48ad314dfd Author: Pablo Neira Ayuso Date: Mon Nov 17 21:40:23 2025 +0000 netfilter: nf_tables: reject duplicate device on updates commit cf5fb87fcdaaaafec55dcc0dc5a9e15ead343973 upstream. A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device. Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case. WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150 Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable") Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit cbbe9170ca2a2cca78344de8256c34ed7f57b27e Author: Dan Carpenter Date: Sat Nov 1 16:25:48 2025 +0300 mtd: onenand: Pass correct pointer to IRQ handler [ Upstream commit 97315e7c901a1de60e8ca9b11e0e96d0f9253e18 ] This was supposed to pass "onenand" instead of "&onenand" with the ampersand. Passing a random stack address which will be gone when the function ends makes no sense. However the good thing is that the pointer is never used, so this doesn't cause a problem at run time. Fixes: e23abf4b7743 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method") Signed-off-by: Dan Carpenter Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 20067f737dc05a495c99a063d135dfecb56b3e4f Author: Eric Biggers Date: Tue Nov 11 12:29:46 2025 -0800 lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN commit 44e8241c51f762aafa50ed116da68fd6ecdcc954 upstream. On big endian arm kernels, the arm optimized Curve25519 code produces incorrect outputs and fails the Curve25519 test. This has been true ever since this code was added. It seems that hardly anyone (or even no one?) actually uses big endian arm kernels. But as long as they're ostensibly supported, we should disable this code on them so that it's not accidentally used. Note: for future-proofing, use !CPU_BIG_ENDIAN instead of CPU_LITTLE_ENDIAN. Both of these are arch-specific options that could get removed in the future if big endian support gets dropped. Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Cc: stable@vger.kernel.org Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251104054906.716914-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit b69f19244c2b6475c8a6eb72f0fb0d53509e48cd Author: Jakub Acs Date: Fri Nov 7 12:17:55 2025 +0000 mm/ksm: fix flag-dropping behavior in ksm_madvise [ Upstream commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 ] syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 [ 44.617726] Call Trace: [ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/ Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") Signed-off-by: Jakub Acs Signed-off-by: Miguel Ojeda Acked-by: David Hildenbrand Acked-by: SeongJae Park Tested-by: Alice Ryhl Tested-by: Miguel Ojeda Cc: Xu Xin Cc: Chengming Zhou Cc: Peter Xu Cc: Axel Rasmussen Cc: Signed-off-by: Andrew Morton [ acsjakub: drop rust-compatibility change (no rust in 5.15) ] Signed-off-by: Jakub Acs Signed-off-by: Sasha Levin commit 1a6ed803c4b17e06aab1a88c4d8fb766b6cbafe0 Author: Matthieu Baerts (NGI0) Date: Thu Nov 13 16:22:57 2025 +0100 mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR [ Upstream commit e84cb860ac3ce67ec6ecc364433fd5b412c448bc ] The special C-flag case expects the ADD_ADDR to be received when switching to 'fully-established'. But for various reasons, the ADD_ADDR could be sent after the "4th ACK", and the special case doesn't work. On NIPA, the new test validating this special case for the C-flag failed a few times, e.g. 102 default limits, server deny join id 0 syn rx [FAIL] got 0 JOIN[s] syn rx expected 2 Server ns stats (...) MPTcpExtAddAddrTx 1 MPTcpExtEchoAdd 1 Client ns stats (...) MPTcpExtAddAddr 1 MPTcpExtEchoAddTx 1 synack rx [FAIL] got 0 JOIN[s] synack rx expected 2 ack rx [FAIL] got 0 JOIN[s] ack rx expected 2 join Rx [FAIL] see above syn tx [FAIL] got 0 JOIN[s] syn tx expected 2 join Tx [FAIL] see above I had a suspicion about what the issue could be: the ADD_ADDR might have been received after the switch to the 'fully-established' state. The issue was not easy to reproduce. The packet capture shown that the ADD_ADDR can indeed be sent with a delay, and the client would not try to establish subflows to it as expected. A simple fix is not to mark the endpoints as 'used' in the C-flag case, when looking at creating subflows to the remote initial IP address and port. In this case, there is no need to try. Note: newly added fullmesh endpoints will still continue to be used as expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case. Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-8207030cb0e8@kernel.org Signed-off-by: Jakub Kicinski [ applied to pm_netlink.c instead of pm_kernel.c ] Signed-off-by: Sasha Levin [ I took the version from Sasha from v6.1, and fixed an additional conflict in pm_netlink.c, because commit a88c9e496937 ("mptcp: do not block subflows creation on errors") is not in this version and changed the code around: check_work_pending() is now called directly, followed by a return instead of a goto. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Sasha Levin commit c4cdd143c35974a2cedd000fa9eb3accc3023b20 Author: Eric Dumazet Date: Wed Nov 12 12:55:16 2025 +0000 bpf: Add bpf_prog_run_data_pointers() [ Upstream commit 4ef92743625818932b9c320152b58274c05e5053 ] syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end. Fixes: ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block") Reported-by: syzbot Closes: https://lore.kernel.org/netdev/6913437c.a70a0220.22f260.013b.GAE@google.com/ Signed-off-by: Eric Dumazet Signed-off-by: Martin KaFai Lau Reviewed-by: Victor Nogueira Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20251112125516.1563021-1-edumazet@google.com Signed-off-by: Sasha Levin commit 9f282104627be5fbded3102ff9004f753c55a063 Author: Haein Lee Date: Wed Nov 12 00:37:54 2025 +0900 ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd [ Upstream commit 632108ec072ad64c8c83db6e16a7efee29ebfb74 ] In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor. Fixes: 17156f23e93c ("ALSA: usb: add UAC3 BADD profiles support") Signed-off-by: Haein Lee Link: https://patch.msgid.link/vwhzmoba9j2f.vwhzmob9u9e2.g6@dooray.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6ec3bfe0ad7391c3150d6bd32a3977cf96826f54 Author: Trond Myklebust Date: Fri Oct 31 10:51:42 2025 -0400 NFSv4: Fix an incorrect parameter when calling nfs4_call_sync() [ Upstream commit 1f214e9c3aef2d0936be971072e991d78a174d71 ] The Smatch static checker noted that in _nfs4_proc_lookupp(), the flag RPC_TASK_TIMEOUT is being passed as an argument to nfs4_init_sequence(), which is clearly incorrect. Since LOOKUPP is an idempotent operation, nfs4_init_sequence() should not ask the server to cache the result. The RPC_TASK_TIMEOUT flag needs to be passed down to the RPC layer. Reported-by: Dan Carpenter Reported-by: Harshit Mogalapalli Fixes: 76998ebb9158 ("NFSv4: Observe the NFS_MOUNT_SOFTREVAL flag in _nfs4_proc_lookupp") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 709e5c088f9c99a5cf2c1d1c6ce58f2cca7ab173 Author: Ian Forbes Date: Tue Oct 21 14:01:28 2025 -0500 drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE [ Upstream commit 32b415a9dc2c212e809b7ebc2b14bc3fbda2b9af ] This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access. Fixes: 8ce75f8ab904 ("drm/vmwgfx: Update device includes for DX device functionality") Reported-by: Rohit Keshri Signed-off-by: Ian Forbes Reviewed-by: Maaz Mombasawala Signed-off-by: Zack Rusin Link: https://patch.msgid.link/20251021190128.13014-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit bfa4f33f0a43a512244d4b67d6da3c3251840462 Author: Haotian Zhang Date: Wed Nov 5 14:22:46 2025 +0800 ASoC: cs4271: Fix regulator leak on probe failure [ Upstream commit 6b6eddc63ce871897d3a5bc4f8f593e698aef104 ] The probe function enables regulators at the beginning but fails to disable them in its error handling path. If any operation after enabling the regulators fails, the probe will exit with an error, leaving the regulators permanently enabled, which could lead to a resource leak. Add a proper error handling path to call regulator_bulk_disable() before returning an error. Fixes: 9a397f473657 ("ASoC: cs4271: add regulator consumer support") Signed-off-by: Haotian Zhang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251105062246.1955-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ee29c2319ee884d28ccc885c4a1c15effb13d448 Author: Haotian Zhang Date: Wed Oct 29 01:28:28 2025 +0800 regulator: fixed: fix GPIO descriptor leak on register failure [ Upstream commit 636f4618b1cd96f6b5a2b8c7c4f665c8533ecf13 ] In the commit referenced by the Fixes tag, devm_gpiod_get_optional() was replaced by manual GPIO management, relying on the regulator core to release the GPIO descriptor. However, this approach does not account for the error path: when regulator registration fails, the core never takes over the GPIO, resulting in a resource leak. Add gpiod_put() before returning on regulator registration failure. Fixes: 5e6f3ae5c13b ("regulator: fixed: Let core handle GPIO descriptor") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251028172828.625-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5c1fd2b81e13e3c97c969815a6d5557cd8a8d3f8 Author: Shuai Xue Date: Sat Sep 13 10:32:24 2025 +0800 acpi,srat: Fix incorrect device handle check for Generic Initiator [ Upstream commit 7c3643f204edf1c5edb12b36b34838683ee5f8dc ] The Generic Initiator Affinity Structure in SRAT table uses device handle type field to indicate the device type. According to ACPI specification, the device handle type value of 1 represents PCI device, not 0. Fixes: 894c26a1c274 ("ACPI: Support Generic Initiator only domains") Reported-by: Wu Zongyong Signed-off-by: Shuai Xue Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20250913023224.39281-1-xueshuai@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 9d1d7858fc5b33e3e09c6b5c09e9522fc36f438e Author: Pauli Virtanen Date: Mon Nov 3 20:29:48 2025 +0200 Bluetooth: L2CAP: export l2cap_chan_hold for modules [ Upstream commit e060088db0bdf7932e0e3c2d24b7371c4c5b867c ] l2cap_chan_put() is exported, so export also l2cap_chan_hold() for modules. l2cap_chan_hold() has use case in net/bluetooth/6lowpan.c Signed-off-by: Pauli Virtanen Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8b1551cacb66f82b85808423b0ca7165f6a6d9c6 Author: Felix Maurer Date: Tue Nov 11 17:29:32 2025 +0100 hsr: Fix supervision frame sending on HSRv0 [ Upstream commit 96a3a03abf3d8cc38cd9cb0d280235fbcf7c3f7f ] On HSRv0, no supervision frames were sent. The supervison frames were generated successfully, but failed the check for a sufficiently long mac header, i.e., at least sizeof(struct hsr_ethhdr), in hsr_fill_frame_info() because the mac header only contained the ethernet header. Fix this by including the HSR header in the mac header when generating HSR supervision frames. Note that the mac header now also includes the TLV fields. This matches how we set the headers on rx and also the size of struct hsrv0_ethhdr_sp. Reported-by: Hangbin Liu Closes: https://lore.kernel.org/netdev/aMONxDXkzBZZRfE5@fedora/ Fixes: 9cfb5e7f0ded ("net: hsr: fix hsr_init_sk() vs network/transport headers.") Signed-off-by: Felix Maurer Reviewed-by: Sebastian Andrzej Siewior Tested-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/4354114fea9a642fe71f49aeeb6c6159d1d61840.1762876095.git.fmaurer@redhat.com Tested-by: Hangbin Liu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f8706e15710f4e8f4532308d95eda7c523ae4ee2 Author: Eric Dumazet Date: Sun Nov 9 16:12:15 2025 +0000 net_sched: limit try_bulk_dequeue_skb() batches [ Upstream commit 0345552a653ce5542affeb69ac5aa52177a5199b ] After commit 100dfa74cad9 ("inet: dev_queue_xmit() llist adoption") I started seeing many qdisc requeues on IDPF under high TX workload. $ tc -s qd sh dev eth1 handle 1: ; sleep 1; tc -s qd sh dev eth1 handle 1: qdisc mq 1: root Sent 43534617319319 bytes 268186451819 pkt (dropped 0, overlimits 0 requeues 3532840114) backlog 1056Kb 6675p requeues 3532840114 qdisc mq 1: root Sent 43554665866695 bytes 268309964788 pkt (dropped 0, overlimits 0 requeues 3537737653) backlog 781164b 4822p requeues 3537737653 This is caused by try_bulk_dequeue_skb() being only limited by BQL budget. perf record -C120-239 -e qdisc:qdisc_dequeue sleep 1 ; perf script ... netperf 75332 [146] 2711.138269: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1292 skbaddr=0xff378005a1e9f200 netperf 75332 [146] 2711.138953: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1213 skbaddr=0xff378004d607a500 netperf 75330 [144] 2711.139631: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1233 skbaddr=0xff3780046be20100 netperf 75333 [147] 2711.140356: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1093 skbaddr=0xff37800514845b00 netperf 75337 [151] 2711.141037: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1353 skbaddr=0xff37800460753300 netperf 75337 [151] 2711.141877: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1367 skbaddr=0xff378004e72c7b00 netperf 75330 [144] 2711.142643: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1202 skbaddr=0xff3780045bd60000 ... This is bad because : 1) Large batches hold one victim cpu for a very long time. 2) Driver often hit their own TX ring limit (all slots are used). 3) We call dev_requeue_skb() 4) Requeues are using a FIFO (q->gso_skb), breaking qdisc ability to implement FQ or priority scheduling. 5) dequeue_skb() gets packets from q->gso_skb one skb at a time with no xmit_more support. This is causing many spinlock games between the qdisc and the device driver. Requeues were supposed to be very rare, lets keep them this way. Limit batch sizes to /proc/sys/net/core/dev_weight (default 64) as __qdisc_run() was designed to use. Fixes: 5772e9a3463b ("qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE") Signed-off-by: Eric Dumazet Reviewed-by: Toke Høiland-Jørgensen Acked-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/20251109161215.2574081-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5af7ec404e85d20b321413781b678ccbccbba8ae Author: Gal Pressman Date: Sun Nov 9 11:37:52 2025 +0200 net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps [ Upstream commit 43b27d1bd88a4bce34ec2437d103acfae9655f9e ] Add validation to reject rates exceeding 255 Gbps that would overflow the 8 bits max bandwidth field. Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate") Signed-off-by: Gal Pressman Reviewed-by: Nimrod Oren Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1762681073-1084058-5-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 727f158d9a8a5e1e74059f7bfecfab68a2aae133 Author: Gal Pressman Date: Sun Nov 9 11:37:51 2025 +0200 net/mlx5e: Fix maxrate wraparound in threshold between units [ Upstream commit a7bf4d5063c7837096aab2853224eb23628514d9 ] The previous calculation used roundup() which caused an overflow for rates between 25.5Gbps and 26Gbps. For example, a rate of 25.6Gbps would result in using 100Mbps units with value of 256, which would overflow the 8 bits field. Simplify the upper_limit_mbps calculation by removing the unnecessary roundup, and adjust the comparison to use <= to correctly handle the boundary condition. Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate") Signed-off-by: Gal Pressman Reviewed-by: Nimrod Oren Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1762681073-1084058-4-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 37f0680887c5aeba9a433fe04b35169010568bb1 Author: Ranganath V N Date: Sun Nov 9 14:43:36 2025 +0530 net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak [ Upstream commit ce50039be49eea9b4cd8873ca6eccded1b4a130a ] Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak. Reported-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee Tested-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com Fixes: ef6980b6becb ("introduce IFE action") Signed-off-by: Ranganath V N Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20251109091336.9277-3-vnranganath.20@gmail.com Acked-by: Cong Wang Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 218b67c8c8246d47a2a7910eae80abe4861fe2b7 Author: Ranganath V N Date: Sun Nov 9 14:43:35 2025 +0530 net: sched: act_connmark: initialize struct tc_ife to fix kernel leak [ Upstream commit 62b656e43eaeae445a39cd8021a4f47065af4389 ] In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. Reported-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee Tested-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com Fixes: 22a5dc0e5e3e ("net: sched: Introduce connmark action") Signed-off-by: Ranganath V N Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20251109091336.9277-2-vnranganath.20@gmail.com Acked-by: Cong Wang Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit def0860b2cafab13994c12881090fc4061187329 Author: Eric Dumazet Date: Wed Jul 9 09:01:54 2025 +0000 net_sched: act_connmark: use RCU in tcf_connmark_dump() [ Upstream commit 0d752877705c0252ef2726e4c63c5573f048951c ] Also storing tcf_action into struct tcf_connmark_parms makes sure there is no discrepancy in tcf_connmark_act(). Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250709090204.797558-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 62b656e43eae ("net: sched: act_connmark: initialize struct tc_ife to fix kernel leak") Signed-off-by: Sasha Levin commit 0d14e8ba20cfeac79be2f8671e6e206b58b79dc7 Author: Pedro Tammela Date: Tue Feb 14 18:15:32 2023 -0300 net/sched: act_connmark: transition to percpu stats and rcu [ Upstream commit 288864effe33885988d53faf7830b35cb9a84c7a ] The tc action act_connmark was using shared stats and taking the per action lock in the datapath. Improve it by using percpu stats and rcu. perf before: - 13.55% tcf_connmark_act - 81.18% _raw_spin_lock 80.46% native_queued_spin_lock_slowpath perf after: - 2.85% tcf_connmark_act tdc results: 1..15 ok 1 2002 - Add valid connmark action with defaults ok 2 56a5 - Add valid connmark action with control pass ok 3 7c66 - Add valid connmark action with control drop ok 4 a913 - Add valid connmark action with control pipe ok 5 bdd8 - Add valid connmark action with control reclassify ok 6 b8be - Add valid connmark action with control continue ok 7 d8a6 - Add valid connmark action with control jump ok 8 aae8 - Add valid connmark action with zone argument ok 9 2f0b - Add valid connmark action with invalid zone argument ok 10 9305 - Add connmark action with unsupported argument ok 11 71ca - Add valid connmark action and replace it ok 12 5f8f - Add valid connmark action with cookie ok 13 c506 - Replace connmark with invalid goto chain control ok 14 6571 - Delete connmark action with valid index ok 15 3426 - Delete connmark action with invalid index Reviewed-by: Jamal Hadi Salim Signed-off-by: Pedro Tammela Signed-off-by: Paolo Abeni Stable-dep-of: 62b656e43eae ("net: sched: act_connmark: initialize struct tc_ife to fix kernel leak") Signed-off-by: Sasha Levin commit b99642817f60360915cee7f049e27bfa2e667bf8 Author: Zhengchao Shao Date: Thu Sep 8 12:14:36 2022 +0800 net: sched: act_connmark: get rid of tcf_connmark_walker and tcf_connmark_search [ Upstream commit c4d2497032ae31d234425648bf2720dfb1688796 ] tcf_connmark_walker() and tcf_connmark_search() do the same thing as generic walk/search function, so remove them. Signed-off-by: Zhengchao Shao Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Stable-dep-of: 62b656e43eae ("net: sched: act_connmark: initialize struct tc_ife to fix kernel leak") Signed-off-by: Sasha Levin commit 6a45a97e0099188f25897c92cac317cedc2159ba Author: Zhengchao Shao Date: Thu Sep 8 12:14:33 2022 +0800 net: sched: act: move global static variable net_id to tc_action_ops [ Upstream commit acd0a7ab6334f35c3720120d53f79eb8e9b3ac2e ] Each tc action module has a corresponding net_id, so put net_id directly into the structure tc_action_ops. Signed-off-by: Zhengchao Shao Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Stable-dep-of: 62b656e43eae ("net: sched: act_connmark: initialize struct tc_ife to fix kernel leak") Signed-off-by: Sasha Levin commit 659e94c35a3f0c35a9edbf3fcffb996e886f3908 Author: Benjamin Berg Date: Mon Nov 10 14:26:18 2025 +0200 wifi: mac80211: skip rate verification for not captured PSDUs [ Upstream commit 7fe0d21f5633af8c3fab9f0ef0706c6156623484 ] If for example the sniffer did not follow any AIDs in an MU frame, then some of the information may not be filled in or is even expected to be invalid. As an example, in that case it is expected that Nss is zero. Fixes: 2ff5e52e7836 ("radiotap: add 0-length PSDU "not captured" type") Signed-off-by: Benjamin Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110142554.83a2858ee15b.I9f78ce7984872f474722f9278691ae16378f0a3e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1040834078acadd06667a2f5f3c04eaacaeac744 Author: Buday Csaba Date: Sat Nov 8 07:49:22 2025 +0100 net: mdio: fix resource leak in mdiobus_register_device() [ Upstream commit e6ca8f533ed41129fcf052297718f417f021cc7d ] Fix a possible leak in mdiobus_register_device() when both a reset-gpio and a reset-controller are present. Clean up the already claimed reset-gpio, when the registration of the reset-controller fails, so when an error code is returned, the device retains its state before the registration attempt. Link: https://lore.kernel.org/all/20251106144603.39053c81@kernel.org/ Fixes: 71dd6c0dff51 ("net: phy: add support for reset-controller") Signed-off-by: Buday Csaba Link: https://patch.msgid.link/4b419377f8dd7d2f63f919d0f74a336c734f8fff.1762584481.git.buday.csaba@prolan.hu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 51b8f0ab888f8aa5dfac954918864eeda8c12c19 Author: Kuniyuki Iwashima Date: Fri Nov 7 06:40:25 2025 +0000 tipc: Fix use-after-free in tipc_mon_reinit_self(). [ Upstream commit 0725e6afb55128be21a2ca36e9674f573ccec173 ] syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6088: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2422 [inline] slab_free mm/slub.c:4695 [inline] kfree+0x195/0x550 mm/slub.c:4894 tipc_l2_device_event+0x380/0x650 net/tipc/bearer.c:-1 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline] call_netdevice_notifiers net/core/dev.c:2281 [inline] unregister_netdevice_many_notify+0x14d7/0x1fe0 net/core/dev.c:12166 unregister_netdevice_many net/core/dev.c:12229 [inline] unregister_netdevice_queue+0x33c/0x380 net/core/dev.c:12073 unregister_netdevice include/linux/netdevice.h:3385 [inline] __tun_detach+0xe4d/0x1620 drivers/net/tun.c:621 tun_detach drivers/net/tun.c:637 [inline] tun_chr_close+0x10d/0x1c0 drivers/net/tun.c:3433 __fput+0x458/0xa80 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated") Reported-by: syzbot+d7dad7fd4b3921104957@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/690c323a.050a0220.baf87.007f.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251107064038.2361188-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8a695769c1e81f0d9f7391754c52d0a97db7d0c8 Author: D. Wythe Date: Fri Nov 7 10:40:29 2025 +0800 net/smc: fix mismatch between CLC header and proposal [ Upstream commit ec33f2e5a2d0dbbfd71435209aee812fdc9369b8 ] The current CLC proposal message construction uses a mix of `ini->smc_type_v1/v2` and `pclc_base->hdr.typev1/v2` to decide whether to include optional extensions (IPv6 prefix extension for v1, and v2 extension). This leads to a critical inconsistency: when `smc_clc_prfx_set()` fails - for example, in IPv6-only environments with only link-local addresses, or when the local IP address and the outgoing interface’s network address are not in the same subnet. As a result, the proposal message is assembled using the stale `ini->smc_type_v1` value—causing the IPv6 prefix extension to be included even though the header indicates v1 is not supported. The peer then receives a malformed CLC proposal where the header type does not match the payload, and immediately resets the connection. The fix ensures consistency between the CLC header flags and the actual payload by synchronizing `ini->smc_type_v1` with `pclc_base->hdr.typev1` when prefix setup fails. Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal") Signed-off-by: D. Wythe Reviewed-by: Alexandra Winter Link: https://patch.msgid.link/20251107024029.88753-1-alibuda@linux.alibaba.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abb086b9a95d0ed3b757ee59964ba3c4e4b2fc1a Author: Eric Dumazet Date: Thu Nov 6 11:10:54 2025 +0000 sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto [ Upstream commit 1534ff77757e44bcc4b98d0196bc5c0052fce5fa ] syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline] Fixes: b58537a1f562 ("net: sctp: fix permissions for rto_alpha and rto_beta knobs") Reported-by: syzbot+f8c46c8b2b7f6e076e99@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/690c81ae.050a0220.3d0d33.014e.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Daniel Borkmann Acked-by: Xin Long Link: https://patch.msgid.link/20251106111054.3288127-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17ef29586b76d35352d1c490fcf79fc5c93bf461 Author: Pauli Virtanen Date: Mon Nov 3 20:29:49 2025 +0200 Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions [ Upstream commit 98454bc812f3611551e4b1f81732da4aa7b9597e ] disconnect_all_peers() calls sleeping function (l2cap_chan_close) under spinlock. Holding the lock doesn't actually do any good -- we work on a local copy of the list, and the lock doesn't protect against peer->chan having already been freed. Fix by taking refcounts of peer->chan instead. Clean up the code and old comments a bit. Take devices_lock instead of RCU, because the kfree_rcu(); l2cap_chan_put(); construct in chan_close_cb() does not guarantee peer->chan is necessarily valid in RCU. Also take l2cap_chan_lock() which is required for l2cap_chan_close(). Log: (bluez 6lowpan-tester Client Connect - Disable) ------ BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 ... ... l2cap_send_disconn_req (net/bluetooth/l2cap_core.c:938 net/bluetooth/l2cap_core.c:1495) ... ? __pfx_l2cap_chan_close (net/bluetooth/l2cap_core.c:809) do_enable_set (net/bluetooth/6lowpan.c:1048 net/bluetooth/6lowpan.c:1068) ------ Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2f2b940e7fa3134702f2e8794d371af9fca4d2d6 Author: Pauli Virtanen Date: Mon Nov 3 20:29:47 2025 +0200 Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type confusion [ Upstream commit b454505bf57a2e4f5d49951d4deb03730a9348d9 ] Bluetooth 6lowpan.c confuses BDADDR_LE and ADDR_LE_DEV address types, e.g. debugfs "connect" command takes the former, and "disconnect" and "connect" to already connected device take the latter. This is due to using same value both for l2cap_chan_connect and hci_conn_hash_lookup_le which take different dst_type values. Fix address type passed to hci_conn_hash_lookup_le(). Retain the debugfs API difference between "connect" and "disconnect" commands since it's been like this since 2015 and nobody apparently complained. Fixes: f5ad4ffceba0 ("Bluetooth: 6lowpan: Use hci_conn_hash_lookup_le() when possible") Reviewed-by: Paul Menzel Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d566e9a2bfc848941b091ffd5f4e12c4e889d818 Author: Pauli Virtanen Date: Mon Nov 3 20:29:46 2025 +0200 Bluetooth: 6lowpan: reset link-local header on ipv6 recv path [ Upstream commit 3b78f50918276ab28fb22eac9aa49401ac436a3b ] Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: ... packet_rcv (net/packet/af_packet.c:2152) ... __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------ Fixes: 18722c247023 ("Bluetooth: Enable 6LoWPAN support for BT LE devices") Reviewed-by: Paul Menzel Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7a6d1e740220ff9dfcb6a8c994d6ba49e76db198 Author: Raphael Pinsonneault-Thibeault Date: Wed Nov 5 14:28:41 2025 -0500 Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF [ Upstream commit 23d22f2f71768034d6ef86168213843fc49bf550 ] There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling "usb_driver_release_interface(&btusb_driver, data->intf)" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd. Reported-by: syzbot+2fc81b50a4f8263a159b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2fc81b50a4f8263a159b Tested-by: syzbot+2fc81b50a4f8263a159b@syzkaller.appspotmail.com Fixes: fd913ef7ce619 ("Bluetooth: btusb: Add out-of-band wakeup support") Signed-off-by: Raphael Pinsonneault-Thibeault Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d11c10bce6f479e9f781e5dd94ed140e92716800 Author: Wei Fang Date: Thu Nov 6 10:14:21 2025 +0800 net: fec: correct rx_bytes statistic for the case SHIFT16 is set [ Upstream commit ad17e7e92a7c52ce70bb764813fcf99464f96903 ] Two additional bytes in front of each frame received into the RX FIFO if SHIFT16 is set, so we need to subtract the extra two bytes from pkt_len to correct the statistic of rx_bytes. Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware") Signed-off-by: Wei Fang Reviewed-by: Frank Li Link: https://patch.msgid.link/20251106021421.2096585-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd60d0ba60f8b3d020f828f60c3d3a15c17babf8 Author: Sharique Mohammad Date: Wed Oct 15 15:42:15 2025 +0200 ASoC: max98090/91: fixed max98091 ALSA widget powering up/down [ Upstream commit 7a37291ed40a33a5f6c3d370fdde5ee0d8f7d0e4 ] The widgets DMIC3_ENA and DMIC4_ENA must be defined in the DAPM suppy widget, just like DMICL_ENA and DMICR_ENA. Whenever they are turned on or off, the required startup or shutdown sequences must be taken care by the max98090_shdn_event. Signed-off-by: Sharique Mohammad Link: https://patch.msgid.link/20251015134215.750001-1-sharq0406@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 65258557686629d77de3c29dcc1bde3065582bae Author: Scott Mayhew Date: Thu Oct 9 16:42:12 2025 -0400 NFS: check if suid/sgid was cleared after a write as needed [ Upstream commit 9ff022f3820a31507cb93be6661bf5f3ca0609a4 ] I noticed xfstests generic/193 and generic/355 started failing against knfsd after commit e7a8ebc305f2 ("NFSD: Offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE"). I ran those same tests against ONTAP (which has had write delegation support for a lot longer than knfsd) and they fail there too... so while it's a new failure against knfsd, it isn't an entirely new failure. Add the NFS_INO_REVAL_FORCED flag so that the presence of a delegation doesn't keep the inode from being revalidated to fetch the updated mode. Signed-off-by: Scott Mayhew Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9727b5dc98c331448e51f9dfc2d124e09d1e1c44 Author: Tristan Lobb Date: Sun Sep 28 18:25:43 2025 +0200 HID: quirks: avoid Cooler Master MM712 dongle wakeup bug [ Upstream commit 0be4253bf878d9aaa2b96031ac8683fceeb81480 ] The Cooler Master Mice Dongle includes a vendor defined HID interface alongside its mouse interface. Not polling it will cause the mouse to stop responding to polls on any interface once woken up again after going into power saving mode. Add the HID_QUIRK_ALWAYS_POLL quirk alongside the Cooler Master VID and the Dongle's PID. Signed-off-by: Tristan Lobb Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d2560884113c0e3148e9fb9ffabec2bed1e954b1 Author: Joshua Watt Date: Thu Oct 9 15:48:04 2025 -0600 NFS4: Fix state renewals missing after boot [ Upstream commit 9bb3baa9d1604cd20f49ae7dac9306b4037a0e7a ] Since the last renewal time was initialized to 0 and jiffies start counting at -5 minutes, any clients connected in the first 5 minutes after a reboot would have their renewal timer set to a very long interval. If the connection was idle, this would result in the client state timing out on the server and the next call to the server would return NFS4ERR_BADSESSION. Fix this by initializing the last renewal time to the current jiffies instead of 0. Signed-off-by: Joshua Watt Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit e5d5b4228e05ec506d8e2baa7ab76f813cb5f842 Author: Danil Skrebenkov Date: Fri Sep 19 16:28:46 2025 +0300 RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors [ Upstream commit ae9e9f3d67dcef7582a4524047b01e33c5185ddb ] openSBI v1.7 adds harts checks for ipi operations. Especially it adds comparison between hmask passed as an argument from linux and mask of online harts (from openSBI side). If they don't fit each other the error occurs. When cpu is offline, cpu_online_mask is explicitly cleared in __cpu_disable. However, there is no explicit clearing of mm_cpumask. mm_cpumask is used for rfence operations that call openSBI RFENCE extension which uses ipi to remote harts. If hart is offline there may be error if mask of linux is not as mask of online harts in openSBI. this patch adds explicit clearing of mm_cpumask for offline hart. Signed-off-by: Danil Skrebenkov Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20250919132849.31676-1-danil.skrebenkov@cloudbear.ru [pjw@kernel.org: rewrote subject line for clarity] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit be5a8537b2b91b2f977304714322f0e7662367f1 Author: Peter Zijlstra Date: Thu Nov 6 11:50:00 2025 +0100 compiler_types: Move unused static inline functions warning to W=2 [ Upstream commit 9818af18db4bfefd320d0fef41390a616365e6f7 ] Per Nathan, clang catches unused "static inline" functions in C files since commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Linus said: > So I entirely ignore W=1 issues, because I think so many of the extra > warnings are bogus. > > But if this one in particular is causing more problems than most - > some teams do seem to use W=1 as part of their test builds - it's fine > to send me a patch that just moves bad warnings to W=2. > > And if anybody uses W=2 for their test builds, that's THEIR problem.. Here is the change to bump the warning from W=1 to W=2. Fixes: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Signed-off-by: Peter Zijlstra Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20251106105000.2103276-1-andriy.shevchenko@linux.intel.com [nathan: Adjust comment as well] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit e988634d7aae7214818b9c86cd7ef9e78c84b02d Author: Janusz Krzysztofik Date: Thu Oct 23 10:25:19 2025 +0200 drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD [ Upstream commit 84bbe327a5cbb060f3321c9d9d4d53936fc1ef9b ] On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c2618eac59 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti Signed-off-by: Janusz Krzysztofik Reviewed-by: Sebastian Brzezinka Reviewed-by: Krzysztof Karas Acked-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20251023082925.351307-6-janusz.krzysztofik@linux.intel.com (cherry picked from commit 648ef1324add1c2e2b6041cdf0b28d31fbca5f13) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 7d316c3c9e53ba4ba34148e465730ebf6961ee8e Author: Jakub Kicinski Date: Mon Mar 25 08:56:11 2024 -0700 selftests: netdevsim: set test timeout to 10 minutes commit afbf75e8da8ce8a0698212953d350697bb4355a6 upstream. The longest running netdevsim test, nexthop.sh, currently takes 5 min to finish. Around 260s to be exact, and 310s on a debug kernel. The default timeout in selftest is 45sec, so we need an explicit config. Give ourselves some headroom and use 10min. Commit under Fixes isn't really to "blame" but prior to that netdevsim tests weren't integrated with kselftest infra so blaming the tests themselves doesn't seem right, either. Fixes: 8ff25dac88f6 ("netdevsim: add Makefile for selftests") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3694a618609bacffb6e23ad62cc59e63ac176228 Author: Krzysztof Kozlowski Date: Fri May 9 09:17:04 2025 +0200 extcon: adc-jack: Cleanup wakeup source only if it was enabled commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream. Driver in the probe enables wakeup source conditionally, so the cleanup path should do the same - do not release the wakeup source memory if it was not allocated. Link: https://lore.kernel.org/lkml/20250509071703.39442-2-krzysztof.kozlowski@linaro.org/ Reported-by: Christophe JAILLET Closes: https://lore.kernel.org/r/22aaebb7-553b-4571-8a43-58a523241082@wanadoo.fr/ Fixes: 78b6a991eb6c ("extcon: adc-jack: Fix wakeup source leaks on device unbind") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit d3eaf1052cd8189aaf5a30eb5615591cf7fa444e Author: Nathan Chancellor Date: Mon Nov 3 12:11:24 2025 -0700 lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC commit 2b81082ad37cc3f28355fb73a6a69b91ff7dbf20 upstream. Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o for GCC unconditionally because clang-min-version will always evaluate to nothing for GCC. Add a check for CONFIG_CC_IS_CLANG to avoid applying the workaround for GCC, which is only needed for clang-17 and older. Cc: stable@vger.kernel.org Fixes: 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") Signed-off-by: Nathan Chancellor Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251103-curve25519-hacl64-fix-kasan-workaround-v2-1-ab581cbd8035@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 3a9f46f5d4670914cdaf6705fac0d671f9038dc7 Author: Yuta Hayama Date: Wed Oct 15 12:07:05 2025 +0900 rtc: rx8025: fix incorrect register reference commit 162f24cbb0f6ec596e7e9f3e91610d79dc805229 upstream. This code is intended to operate on the CTRL1 register, but ctrl[1] is actually CTRL2. Correctly, ctrl[0] is CTRL1. Signed-off-by: Yuta Hayama Fixes: 71af91565052 ("rtc: rx8025: fix 12/24 hour mode detection on RX-8035") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/eae5f479-5d28-4a37-859d-d54794e7628c@lineo.co.jp Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 38771ab159d9ce331c52d4ad13483ea7dccc68dd Author: Zilin Guan Date: Thu Nov 6 12:01:32 2025 +0000 tracing: Fix memory leaks in create_field_var() [ Upstream commit 80f0d631dcc76ee1b7755bfca1d8417d91d71414 ] The function create_field_var() allocates memory for 'val' through create_hist_field() inside parse_atom(), and for 'var' through create_var(), which in turn allocates var->type and var->var.name internally. Simply calling kfree() to release these structures will result in memory leaks. Use destroy_hist_field() to properly free 'val', and explicitly release the memory of var->type and var->var.name before freeing 'var' itself. Link: https://patch.msgid.link/20251106120132.3639920-1-zilin@seu.edu.cn Fixes: 02205a6752f22 ("tracing: Add support for 'field variables'") Signed-off-by: Zilin Guan Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit a304aa58189593986b2caa4af446cf84c15f8119 Author: Kalesh AP Date: Mon Nov 3 16:56:56 2025 -0800 bnxt_en: Fix a possible memory leak in bnxt_ptp_init [ Upstream commit deb8eb39164382f1f67ef8e8af9176baf5e10f2d ] In bnxt_ptp_init(), when ptp_clock_register() fails, the driver is not freeing the memory allocated for ptp_info->pin_config. Fix it to unconditionally free ptp_info->pin_config in bnxt_ptp_free(). Fixes: caf3eedbcd8d ("bnxt_en: 1PPS support for 5750X family chips") Reviewed-by: Pavan Chebbi Reviewed-by: Somnath Kotur Signed-off-by: Kalesh AP Signed-off-by: Michael Chan Link: https://patch.msgid.link/20251104005700.542174-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25979f34feecb4a3a27f17f423232e48024e833a Author: Pavan Chebbi Date: Tue Jan 25 23:40:10 2022 -0500 bnxt_en: PTP: Refactor PTP initialization functions [ Upstream commit 740c342e399981babdd62d0d5beb7c8ec9503a9a ] Making the ptp free and timecounter initialization code into separate functions so that later patches can use them. Cc: Richard Cochran Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Signed-off-by: David S. Miller Stable-dep-of: deb8eb391643 ("bnxt_en: Fix a possible memory leak in bnxt_ptp_init") Signed-off-by: Sasha Levin commit 4e6b9004f01d0fef5b19778399bc5bf55f8c2d71 Author: Qendrim Maxhuni Date: Wed Oct 29 08:57:44 2025 +0100 net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup [ Upstream commit e120f46768d98151ece8756ebd688b0e43dc8b29 ] Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0 Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support") Signed-off-by: Qendrim Maxhuni Link: https://patch.msgid.link/20251029075744.105113-1-qendrim.maxhuni@garderos.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 82b5ddac08436f8d66efeeca31040834243b40c4 Author: Stefan Wiehler Date: Tue Oct 28 17:12:28 2025 +0100 sctp: Hold sock lock while iterating over address list [ Upstream commit f1fc201148c7e684c10a72b6a3375597f28d1ef6 ] Move address list traversal in inet_assoc_attr_size() under the sock lock to avoid holding the RCU read lock. Suggested-by: Xin Long Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler Acked-by: Xin Long Link: https://patch.msgid.link/20251028161506.3294376-4-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72e3fea68eac8d088e44c3dd954e843478e9240e Author: Stefan Wiehler Date: Tue Oct 28 17:12:27 2025 +0100 sctp: Prevent TOCTOU out-of-bounds write [ Upstream commit 95aef86ab231f047bb8085c70666059b58f53c09 ] For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use). Suggested-by: Kuniyuki Iwashima Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler Reviewed-by: Kuniyuki Iwashima Acked-by: Xin Long Link: https://patch.msgid.link/20251028161506.3294376-3-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad5ddc33af9f16da1463a4f65069f10706ed6047 Author: Stefan Wiehler Date: Tue Oct 28 17:12:26 2025 +0100 sctp: Hold RCU read lock while iterating over address list [ Upstream commit 38f50242bf0f237cdc262308d624d333286ec3c5 ] With CONFIG_PROVE_RCU_LIST=y and by executing $ netcat -l --sctp & $ netcat --sctp localhost & $ ss --sctp one can trigger the following Lockdep-RCU splat(s): WARNING: suspicious RCU usage 6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted ----------------------------- net/sctp/diag.c:76 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by ss/215: #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0 #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200 stack backtrace: CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x90 lockdep_rcu_suspicious.cold+0x4e/0xa3 inet_sctp_diag_fill.isra.0+0x4b1/0x5d0 sctp_sock_dump+0x131/0x200 sctp_transport_traverse_process+0x170/0x1b0 ? __pfx_sctp_sock_filter+0x10/0x10 ? __pfx_sctp_sock_dump+0x10/0x10 sctp_diag_dump+0x103/0x140 __inet_diag_dump+0x70/0xb0 netlink_dump+0x148/0x490 __netlink_dump_start+0x1f3/0x2b0 inet_diag_handler_cmd+0xcd/0x100 ? __pfx_inet_diag_dump_start+0x10/0x10 ? __pfx_inet_diag_dump+0x10/0x10 ? __pfx_inet_diag_dump_done+0x10/0x10 sock_diag_rcv_msg+0x18e/0x320 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x4d/0x100 netlink_unicast+0x1d7/0x2b0 netlink_sendmsg+0x203/0x450 ____sys_sendmsg+0x30c/0x340 ___sys_sendmsg+0x94/0xf0 __sys_sendmsg+0x83/0xf0 do_syscall_64+0xbb/0x390 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler Reviewed-by: Kuniyuki Iwashima Acked-by: Xin Long Link: https://patch.msgid.link/20251028161506.3294376-2-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6618c36f6d86c8786b0888f0727b1cf020b59304 Author: Jonas Gorski Date: Sun Nov 2 11:07:57 2025 +0100 net: dsa: b53: stop reading ARL entries if search is done [ Upstream commit 0be04b5fa62a82a9929ca261f6c9f64a3d0a28da ] The switch clears the ARL_SRCH_STDN bit when the search is done, i.e. it finished traversing the ARL table. This means that there will be no valid result, so we should not attempt to read and process any further entries. We only ever check the validity of the entries for 4 ARL bin chips, and only after having passed the first entry to the b53_fdb_copy(). This means that we always pass an invalid entry at the end to the b53_fdb_copy(). b53_fdb_copy() does check the validity though before passing on the entry, so it never gets passed on. On < 4 ARL bin chips, we will even continue reading invalid entries until we reach the result limit. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251102100758.28352-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae52ba1ad2ed1bcbc6e3e5bb32a28f85b6bfcf61 Author: Jonas Gorski Date: Sun Nov 2 11:07:56 2025 +0100 net: dsa: b53: fix enabling ip multicast [ Upstream commit c264294624e956a967a9e2e5fa41e3273340b089 ] In the New Control register bit 1 is either reserved, or has a different function: Out of Range Error Discard When enabled, the ingress port discards any frames if the Length field is between 1500 and 1536 (excluding 1500 and 1536) and with good CRC. The actual bit for enabling IP multicast is bit 0, which was only explicitly enabled for BCM5325 so far. For older switch chips, this bit defaults to 0, so we want to enable it as well, while newer switch chips default to 1, and their documentation says "It is illegal to set this bit to zero." So drop the wrong B53_IPMC_FWD_EN define, enable the IP multicast bit also for other switch chips. While at it, rename it to (B53_)IP_MC as that is how it is called in Broadcom code. Fixes: 63cc54a6f073 ("net: dsa: b53: Fix egress flooding settings") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251102100758.28352-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd8c2419b50b1952f8ca1a7a008a76a9194de634 Author: Jonas Gorski Date: Sat Nov 1 14:28:06 2025 +0100 net: dsa: b53: fix resetting speed and pause on forced link [ Upstream commit b6a8a5477fe9bd6be2b594a88f82f8bba41e6d54 ] There is no guarantee that the port state override registers have their default values, as not all switches support being reset via register or have a reset GPIO. So when forcing port config, we need to make sure to clear all fields, which we currently do not do for the speed and flow control configuration. This can cause flow control stay enabled, or in the case of speed becoming an illegal value, e.g. configured for 1G (0x2), then setting 100M (0x1), results in 0x3 which is invalid. For PORT_OVERRIDE_SPEED_2000M we need to make sure to only clear it on supported chips, as the bit can have different meanings on other chips, e.g. for BCM5389 this controls scanning PHYs for link/speed configuration. Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251101132807.50419-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48df5cc7fd7ca58fddba4909f462c5194dc434d2 Author: Hangbin Liu Date: Thu Oct 30 07:35:39 2025 +0000 net: vlan: sync VLAN features with lower device [ Upstream commit c211f5d7cbd5cb34489d526648bb9c8ecc907dee ] After registering a VLAN device and setting its feature flags, we need to synchronize the VLAN features with the lower device. For example, the VLAN device does not have the NETIF_F_LRO flag, it should be synchronized with the lower device based on the NETIF_F_UPPER_DISABLES definition. As the dev->vlan_features has changed, we need to call netdev_update_features(). The caller must run after netdev_upper_dev_link() links the lower devices, so this patch adds the netdev_update_features() call in register_vlan_dev(). Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack") Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20251030073539.133779-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 82acad39d05ce2d14f51f1c80059da18265c65de Author: Wang Liang Date: Thu Oct 30 12:03:40 2025 +0800 selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing ethtool-common.sh [ Upstream commit d01f8136d46b925798abcf86b35a4021e4cfb8bb ] The script "ethtool-common.sh" is not installed in INSTALL_PATH, and triggers some errors when I try to run the test 'drivers/net/netdevsim/ethtool-coalesce.sh': TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # ./ethtool-coalesce.sh: line 4: ethtool-common.sh: No such file or directory # ./ethtool-coalesce.sh: line 25: make_netdev: command not found # ethtool: bad command line argument(s) # ./ethtool-coalesce.sh: line 124: check: command not found # ./ethtool-coalesce.sh: line 126: [: -eq: unary operator expected # FAILED /0 checks not ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh # exit=1 Install this file to avoid this error. After this patch: TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # PASSED all 22 checks ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh Fixes: fbb8531e58bd ("selftests: extract common functions in ethtool-common.sh") Signed-off-by: Wang Liang Link: https://patch.msgid.link/20251030040340.3258110-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3903664c8838cf2bd0a56f4c91323534dc2e79e Author: David Wei Date: Tue Jan 30 13:46:20 2024 -0800 netdevsim: add Makefile for selftests [ Upstream commit 8ff25dac88f616ebebb30830e3a20f079d7a30c9 ] Add a Makefile for netdevsim selftests and add selftests path to MAINTAINERS Signed-off-by: David Wei Link: https://lore.kernel.org/r/20240130214620.3722189-5-dw@davidwei.uk Signed-off-by: Jakub Kicinski Stable-dep-of: d01f8136d46b ("selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing ethtool-common.sh") Signed-off-by: Sasha Levin commit c2ce8d37e49e4e1ea95564ea335aab75e0b13ebc Author: Anubhav Singh Date: Thu Oct 30 06:04:36 2025 +0000 selftests/net: use destination options instead of hop-by-hop [ Upstream commit f8e8486702abb05b8c734093aab1606af0eac068 ] The GRO self-test, gro.c, currently constructs IPv6 packets containing a Hop-by-Hop Options header (IPPROTO_HOPOPTS) to ensure the GRO path correctly handles IPv6 extension headers. However, network elements may be configured to drop packets with the Hop-by-Hop Options header (HBH). This causes the self-test to fail in environments where such network elements are present. To improve the robustness and reliability of this test in diverse network environments, switch from using IPPROTO_HOPOPTS to IPPROTO_DSTOPTS (Destination Options). The Destination Options header is less likely to be dropped by intermediate routers and still serves the core purpose of the test: validating GRO's handling of an IPv6 extension header. This change ensures the test can execute successfully without being incorrectly failed by network policies outside the kernel's control. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn Signed-off-by: Anubhav Singh Link: https://patch.msgid.link/20251030060436.1556664-1-anubhavsinggh@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 32c3e1cbc2e6ebb556a2c5693664977f982caba9 Author: Richard Gobert Date: Wed Jan 3 15:48:35 2024 +0100 selftests/net: fix GRO coalesce test and add ext header coalesce tests [ Upstream commit 4e321d590cec6053cb3c566413794706035ee638 ] Currently there is no test which checks that IPv6 extension header packets successfully coalesce. This commit adds a test, which verifies two IPv6 packets with HBH extension headers do coalesce, and another test which checks that packets with different extension header data do not coalesce in GRO. I changed the receive socket filter to accept a packet with one extension header. This change exposed a bug in the fragment test -- the old BPF did not accept the fragment packet. I updated correct_num_packets in the fragment test accordingly. Signed-off-by: Richard Gobert Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/69282fed-2415-47e8-b3d3-34939ec3eb56@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: f8e8486702ab ("selftests/net: use destination options instead of hop-by-hop") Signed-off-by: Sasha Levin commit e4603c1c4fd19ef9a3433673eb0cd0a4d9a1725c Author: Anubhav Singh Date: Thu Oct 30 06:28:18 2025 +0000 selftests/net: fix out-of-order delivery of FIN in gro:tcp test [ Upstream commit 02d064de05b1fcca769391fa82d205bed8bb9bf0 ] Due to the gro_sender sending data packets and FIN packets in very quick succession, these are received almost simultaneously by the gro_receiver. FIN packets are sometimes processed before the data packets leading to intermittent (~1/100) test failures. This change adds a delay of 100ms before sending FIN packets in gro:tcp test to avoid the out-of-order delivery. The same mitigation already exists for the gro:ip test. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn Signed-off-by: Anubhav Singh Link: https://patch.msgid.link/20251030062818.1562228-1-anubhavsinggh@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8d549eb5acab5ec43ba61de66b2dac536251238 Author: Jonas Gorski Date: Mon Oct 27 20:46:21 2025 +0100 net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for bcm63xx [ Upstream commit 3d18a84eddde169d6dbf3c72cc5358b988c347d0 ] The internal switch on BCM63XX SoCs will unconditionally add 802.1Q VLAN tags on egress to CPU when 802.1Q mode is enabled. We do this unconditionally since commit ed409f3bbaa5 ("net: dsa: b53: Configure VLANs while not filtering"). This is fine for VLAN aware bridges, but for standalone ports and vlan unaware bridges this means all packets are tagged with the default VID, which is 0. While the kernel will treat that like untagged, this can break userspace applications processing raw packets, expecting untagged traffic, like STP daemons. This also breaks several bridge tests, where the tcpdump output then does not match the expected output anymore. Since 0 isn't a valid VID, just strip out the VLAN tag if we encounter it, unless the priority field is set, since that would be a valid tag again. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Signed-off-by: Jonas Gorski Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20251027194621.133301-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f8d974a0e8c2928cea8fcda601f7f2d834ac1344 Author: Josephine Pfeiffer Date: Mon Oct 27 11:40:43 2025 -0600 riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro [ Upstream commit a74f038fa50e0d33b740f44f862fe856f16de6a8 ] The pt_dump_seq_puts() macro incorrectly uses seq_printf() instead of seq_puts(). This is both a performance issue and conceptually wrong, as the macro name suggests plain string output (puts) but the implementation uses formatted output (printf). The macro is used in ptdump.c:301 to output a newline character. Using seq_printf() adds unnecessary overhead for format string parsing when outputting this constant string. This bug was introduced in commit 59c4da8640cc ("riscv: Add support to dump the kernel page tables") in 2020, which copied the implementation pattern from other architectures that had the same bug. Fixes: 59c4da8640cc ("riscv: Add support to dump the kernel page tables") Signed-off-by: Josephine Pfeiffer Link: https://lore.kernel.org/r/20251018170451.3355496-1-hi@josie.lol Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 53c7a2110285136f67dc5bdefcf3fcbadff6a3be Author: Baochen Qiang Date: Mon Oct 27 09:49:12 2025 +0800 Revert "wifi: ath10k: avoid unnecessary wait for service ready message" commit 2469bb6a6af944755a7d7daf66be90f3b8decbf9 upstream. This reverts commit 51a73f1b2e56b0324b4a3bb8cebc4221b5be4c7a. Although this commit benefits QCA6174, it breaks QCA988x and QCA9984 [1][2]. Since it is not likely to root cause/fix this issue in a short time, revert it to get those chips back. Compile tested only. Fixes: 51a73f1b2e56 ("wifi: ath10k: avoid unnecessary wait for service ready message") Link: https://lore.kernel.org/ath10k/6d41bc00602c33ffbf68781f563ff2e6c6915a3e.camel@gmail.com # [1] Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220671 # [2] Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251027-ath10k-revert-polling-first-change-v1-1-89aaf3bcbfa1@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit b345e06f2d3590844139e70c12ef8dc611aa8eba Author: Kailang Yang Date: Tue Aug 19 14:03:44 2025 +0800 ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm boot again [ Upstream commit f4b3cef55f5f96fdb4e7f9ca90b7d6213689faeb ] There was a similar bug in the past (Bug 217440), which was fixed for this laptop. The same issue is occurring again as of kernel v.6.12.2. The symptoms are very similar - initially audio works but after a warm reboot, the audio completely disappears until the computer is powered off (there is no audio output at all). The issue is also related by caused by a different change now. By bisecting different kernel versions, I found that reverting cc3d0b5dd989 in patch_realtek.c[*] restores the sound and it works fine after the reboot. [*] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/pci/hda/patch_realtek.c?h=v6.12.2&id=4ed7f16070a8475c088ff423b2eb11ba15eb89b6 [ patch description reformatted by tiwai ] Fixes: cc3d0b5dd989 ("ALSA: hda/realtek: Update ALC256 depop procedure") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220109 Signed-off-by: Kailang Yang Link: https://lore.kernel.org/5317ca723c82447a938414fcca85cbf5@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 676ee2061f728bd39b08f08fe851789c1bcb5917 Author: Viacheslav Dubeyko Date: Fri Jun 6 12:04:32 2025 -0700 ceph: add checking of wait_for_completion_killable() return value [ Upstream commit b7ed1e29cfe773d648ca09895b92856bd3a2092d ] The Coverity Scan service has detected the calling of wait_for_completion_killable() without checking the return value in ceph_lock_wait_for_completion() [1]. The CID 1636232 defect contains explanation: "If the function returns an error value, the error value may be mistaken for a normal value. In ceph_lock_wait_for_completion(): Value returned from a function is not checked for errors before being used. (CWE-252)". The patch adds the checking of wait_for_completion_killable() return value and return the error code from ceph_lock_wait_for_completion(). [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232 Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8bff07a8fc0a3d6aec259d5f2136bf066f191040 Author: Valerio Setti Date: Tue Oct 7 00:12:19 2025 +0200 ASoC: meson: aiu-encoder-i2s: fix bit clock polarity [ Upstream commit 4c4ed5e073a923fb3323022e1131cb51ad8df7a0 ] According to I2S specs audio data is sampled on the rising edge of the clock and it can change on the falling one. When operating in normal mode this SoC behaves the opposite so a clock polarity inversion is required in this case. This was tested on an OdroidC2 (Amlogic S905 SoC) board. Signed-off-by: Valerio Setti Reviewed-by: Jerome Brunet Tested-by: Jerome Brunet Link: https://patch.msgid.link/20251007-fix-i2s-polarity-v1-1-86704d9cda10@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1943b69e87b0ab35032d47de0a7fca9a3d1d6fc1 Author: Albin Babu Varghese Date: Fri Oct 3 03:32:09 2025 -0400 fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds [ Upstream commit 3637d34b35b287ab830e66048841ace404382b67 ] Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes. Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190 Suggested-by: Helge Deller Tested-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com Signed-off-by: Albin Babu Varghese Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 6da480c323928ea171939dbc02d0193107c66134 Author: Sakari Ailus Date: Wed Oct 1 13:26:36 2025 +0300 ACPI: property: Return present device nodes only on fwnode interface [ Upstream commit d9f866b2bb3eec38b3734f1fed325ec7c55ccdfa ] fwnode_graph_get_next_subnode() may return fwnode backed by ACPI device nodes and there has been no check these devices are present in the system, unlike there has been on fwnode OF backend. In order to provide consistent behaviour towards callers, add a check for device presence by introducing a new function acpi_get_next_present_subnode(), used as the get_next_child_node() fwnode operation that also checks device node presence. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20251001102636.1272722-2-sakari.ailus@linux.intel.com [ rjw: Kerneldoc comment and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a66596cf5643008f5edf53a10f62a60d1068759e Author: Randall P. Embry Date: Fri Sep 26 18:27:31 2025 +0900 9p: sysfs_init: don't hardcode error to ENOMEM [ Upstream commit 528f218b31aac4bbfc58914d43766a22ab545d48 ] v9fs_sysfs_init() always returned -ENOMEM on failure; return the actual sysfs_create_group() error instead. Signed-off-by: Randall P. Embry Message-ID: <20250926-v9fs_misc-v1-3-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 879f6a7e75c3e7de2923e8503f54944ebf1e5cab Author: Aaron Kling Date: Thu Aug 28 21:48:13 2025 -0500 cpufreq: tegra186: Initialize all cores to max frequencies [ Upstream commit ba6018929165fc914c665f071f8e8cdbac844a49 ] During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores are still at reset values and not reflecting the actual frequency. This causes get calls to fail. Set all cores to their respective max frequency during probe to initialize the registers to working values. Suggested-by: Mikko Perttunen Signed-off-by: Aaron Kling Reviewed-by: Mikko Perttunen Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 435b42a10995ae3227f9ebbd671d4342fa70ffff Author: Randall P. Embry Date: Fri Sep 26 18:27:30 2025 +0900 9p: fix /sys/fs/9p/caches overwriting itself [ Upstream commit 86db0c32f16c5538ddb740f54669ace8f3a1f3d7 ] caches_show() overwrote its buffer on each iteration, so only the last cache tag was visible in sysfs output. Properly append with snprintf(buf + count, …). Signed-off-by: Randall P. Embry Message-ID: <20250926-v9fs_misc-v1-2-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 66f257db400a9dbb407897e8819b0f97dcc4b236 Author: Matthias Schiffer Date: Mon Aug 25 16:08:11 2025 +0200 clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabled [ Upstream commit 1e0d75258bd09323cb452655549e03975992b29e ] As described in AM335x Errata Advisory 1.0.42, WKUP_DEBUGSS_CLKCTRL can't be disabled - the clock module will just be stuck in transitioning state forever, resulting in the following warning message after the wait loop times out: l3-aon-clkctrl:0000:0: failed to disable Just add the clock to enable_init_clks, so no attempt is made to disable it. Signed-off-by: Matthias Schiffer Signed-off-by: Alexander Stein Acked-by: Kevin Hilman Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c50651c205f6ab56c4093076e543dad7fdcb53b8 Author: Ryan Wanner Date: Mon Sep 8 13:07:17 2025 -0700 clk: at91: clk-master: Add check for divide by 3 [ Upstream commit e0237f5635727d64635ec6665e1de9f4cacce35c ] A potential divider for the master clock is div/3. The register configuration for div/3 is MASTER_PRES_MAX. The current bit shifting method does not work for this case. Checking for MASTER_PRES_MAX will ensure the correct decimal value is stored in the system. Signed-off-by: Ryan Wanner Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit e7322da6c50fff964345e39d40479e04ca456a9a Author: Nicolas Ferre Date: Wed Aug 27 16:54:27 2025 +0200 ARM: at91: pm: save and restore ACR during PLL disable/enable [ Upstream commit 0c01fe49651d387776abed6a28541e80c8a93319 ] Add a new word in assembly to store ACR value during the calls to at91_plla_disable/at91_plla_enable macros and use it. Signed-off-by: Nicolas Ferre [cristian.birsan@microchip.com: remove ACR_DEFAULT_PLLA loading] Signed-off-by: Cristian Birsan Link: https://lore.kernel.org/r/20250827145427.46819-4-nicolas.ferre@microchip.com Reviewed-by: Alexandre Belloni Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit a02f2dbdd77ab081b92f129790c531d88f49ba93 Author: Josua Mayer Date: Mon Aug 25 19:54:09 2025 +0200 rtc: pcf2127: clear minute/second interrupt [ Upstream commit a6f1a4f05970664004a9370459c6799c1b2f2dcf ] PCF2127 can generate interrupt every full second or minute configured from control and status register 1, bits MI (1) and SI (0). On interrupt control register 2 bit MSF (7) is set and must be cleared to continue normal operation. While the driver never enables this interrupt on its own, users or firmware may do so - e.g. as an easy way to test the interrupt. Add preprocessor definition for MSF bit and include it in the irq bitmask to ensure minute and second interrupts are cleared when fired. This fixes an issue where the rtc enters a test mode and becomes unresponsive after a second interrupt has fired and is not cleared in time. In this state register writes to control registers have no effect and the interrupt line is kept asserted [1]: [1] userspace commands to put rtc into unresponsive state: $ i2cget -f -y 2 0x51 0x00 0x04 $ i2cset -f -y 2 0x51 0x00 0x05 # set bit 0 SI $ i2cget -f -y 2 0x51 0x00 0x84 # bit 8 EXT_TEST set $ i2cset -f -y 2 0x51 0x00 0x05 # try overwrite control register $ i2cget -f -y 2 0x51 0x00 0x84 # no change Signed-off-by: Josua Mayer Reviewed-by: Bruno Thomsen Link: https://lore.kernel.org/r/20250825-rtc-irq-v1-1-0133319406a7@solid-run.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cebc9f5ee3e312232ac1dd88fce4dee8b96a662b Author: Tiwei Bie Date: Wed Aug 27 08:56:59 2025 +0800 um: Fix help message for ssl-non-raw [ Upstream commit 725e9d81868fcedaeef775948e699955b01631ae ] Add the missing option name in the help message. Additionally, switch to __uml_help(), because this is a global option rather than a per-channel option. Signed-off-by: Tiwei Bie Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 64ef62fb1c4ad0f1b497b8c6d7a4491c03429acb Author: Yikang Yue Date: Sat May 3 20:44:34 2025 -0500 fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink [ Upstream commit 32058c38d3b79a28963a59ac0353644dc24775cd ] The function call new_inode() is a primitive for allocating an inode in memory, rather than planning disk space for it. Therefore, -ENOMEM should be returned as the error code rather than -ENOSPC. To be specific, new_inode()'s call path looks like this: new_inode new_inode_pseudo alloc_inode ops->alloc_inode (hpfs_alloc_inode) alloc_inode_sb kmem_cache_alloc_lru Therefore, the failure of new_inode() indicates a memory presure issue (-ENOMEM), not a lack of disk space. However, the current implementation of hpfs_mkdir/create/mknod/symlink incorrectly returns -ENOSPC when new_inode() fails. This patch fix this by set err to -ENOMEM before the goto statement. BTW, we also noticed that other nested calls within these four functions, like hpfs_alloc_f/dnode and hpfs_add_dirent, might also fail due to memory presure. But similarly, only -ENOSPC is returned. Addressing these will involve code modifications in other functions, and we plan to submit dedicated patches for these issues in the future. For this patch, we focus on new_inode(). Signed-off-by: Yikang Yue Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit f7af3813ccffbf82bf2961a36a900cb302377ab8 Author: austinchang Date: Wed Oct 29 09:35:27 2025 +0000 btrfs: mark dirty extent range for out of bound prealloc extents [ Upstream commit 3b1a4a59a2086badab391687a6a0b86e03048393 ] In btrfs_fallocate(), when the allocated range overlaps with a prealloc extent and the extent starts after i_size, the range doesn't get marked dirty in file_extent_tree. This results in persisting an incorrect disk_i_size for the inode when not using the no-holes feature. This is reproducible since commit 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree"), then became hidden since commit 3d7db6e8bd22 ("btrfs: don't allocate file extent tree for non regular files") and then visible again after commit 8679d2687c35 ("btrfs: initialize inode::file_extent_tree after i_mode has been set"), which fixes the previous commit. The following reproducer triggers the problem: $ cat test.sh MNT=/mnt/test DEV=/dev/vdb mkdir -p $MNT mkfs.btrfs -f -O ^no-holes $DEV mount $DEV $MNT touch $MNT/file1 fallocate -n -o 1M -l 2M $MNT/file1 umount $MNT mount $DEV $MNT len=$((1 * 1024 * 1024)) fallocate -o 1M -l $len $MNT/file1 du --bytes $MNT/file1 umount $MNT mount $DEV $MNT du --bytes $MNT/file1 umount $MNT Running the reproducer gives the following result: $ ./test.sh (...) 2097152 /mnt/test/file1 1048576 /mnt/test/file1 The difference is exactly 1048576 as we assigned. Fix by adding a call to btrfs_inode_set_file_extent_range() in btrfs_fallocate_update_isize(). Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree") Signed-off-by: austinchang Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8a139fe903f35b03e7a6ce37b84502f9e2d18960 Author: Junxian Huang Date: Thu Oct 16 19:40:50 2025 +0800 RDMA/hns: Fix wrong WQE data when QP wraps around [ Upstream commit fe9622011f955e35ba84d3af7b2f2fed31cf8ca1 ] When QP wraps around, WQE data from the previous use at the same position still remains as driver does not clear it. The WQE field layout differs across different opcodes, causing that the fields that are not explicitly assigned for the current opcode retain stale values, and are issued to HW by mistake. Such fields are as follows: * MSG_START_SGE_IDX field in ATOMIC WQE * BLOCK_SIZE and ZBVA fields in FRMR WQE * DirectWQE fields when DirectWQE not used For ATOMIC WQE, always set the latest sge index in MSG_START_SGE_IDX as required by HW. For FRMR WQE and DirectWQE, clear only those unassigned fields instead of the entire WQE to avoid performance penalty. Fixes: 68a997c5d28c ("RDMA/hns: Add FRMR support for hip08") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20251016114051.1963197-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 63bb04cda17311bd25de7fd2faf3618f64c80fee Author: Jacob Moroni Date: Tue Sep 23 14:24:39 2025 +0000 RDMA/irdma: Set irdma_cq cq_num field during CQ create [ Upstream commit 5575b7646b94c0afb0f4c0d86e00e13cf3397a62 ] The driver maintains a CQ table that is used to ensure that a CQ is still valid when processing CQ related AEs. When a CQ is destroyed, the table entry is cleared, using irdma_cq.cq_num as the index. This field was never being set, so it was just always clearing out entry 0. Additionally, the cq_num field size was increased to accommodate HW supporting more than 64K CQs. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20250923142439.943930-1-jmoroni@google.com Acked-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e8805e90ff0ca5ebb7f0fae8ab27a6b5a4596066 Author: Jacob Moroni Date: Tue Sep 23 14:21:28 2025 +0000 RDMA/irdma: Remove unused struct irdma_cq fields [ Upstream commit 880245fd029a8f8ee8fd557c2681d077c1b1a959 ] These fields were set but not used anywhere, so remove them. Link: https://patch.msgid.link/r/20250923142128.943240-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Stable-dep-of: 5575b7646b94 ("RDMA/irdma: Set irdma_cq cq_num field during CQ create") Signed-off-by: Sasha Levin commit 2380d634959a1f98dc07f485abd6badc1ac6b303 Author: Jacob Moroni Date: Tue Sep 23 19:08:50 2025 +0000 RDMA/irdma: Fix SD index calculation [ Upstream commit 8d158f47f1f33d8747e80c3afbea5aa337e59d41 ] In some cases, it is possible for pble_rsrc->next_fpm_addr to be larger than u32, so remove the u32 cast to avoid unintentional truncation. This fixes the following error that can be observed when registering massive memory regions: [ 447.227494] (NULL ib_device): cqp opcode = 0x1f maj_err_code = 0xffff min_err_code = 0x800c [ 447.227505] (NULL ib_device): [Update PE SDs Cmd Error][op_code=21] status=-5 waiting=1 completion_err=1 maj=0xffff min=0x800c Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20250923190850.1022773-1-jmoroni@google.com Acked-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cc9ab6e1a375e4569a14f056050fb4163535e530 Author: Saket Dumbre Date: Fri Sep 12 22:01:04 2025 +0200 ACPICA: Update dsmethod.c to get rid of unused variable warning [ Upstream commit 761dc71c6020d6aa68666e96373342d49a7e9d0a ] All the 3 major C compilers (MSVC, GCC, LLVM/Clang) warn about the unused variable i after the removal of its usage by PR #1031 addressing Issue #1027 Link: https://github.com/acpica/acpica/commit/6d235320 Signed-off-by: Saket Dumbre Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 15afebb9597449c444801d1ff0b8d8b311f950ab Author: Mike Marshall Date: Mon Sep 15 17:40:46 2025 -0400 orangefs: fix xattr related buffer overflow... [ Upstream commit 025e880759c279ec64d0f754fe65bf45961da864 ] Willy Tarreau forwarded me a message from Disclosure with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr "security.capability" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for "security.capability" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture. Signed-off-by: Mike Marshall Reported-by: Stanislav Fort of Aisle Research Signed-off-by: Sasha Levin commit c12ebeacfbaec491e683023dd46336f3fb021584 Author: Dragos Tatulea Date: Fri Sep 26 16:16:05 2025 +0300 page_pool: Clamp pool size to max 16K pages [ Upstream commit a1b501a8c6a87c9265fd03bd004035199e2e8128 ] page_pool_init() returns E2BIG when the page_pool size goes above 32K pages. As some drivers are configuring the page_pool size according to the MTU and ring size, there are cases where this limit is exceeded and the queue creation fails. The page_pool size doesn't have to cover a full queue, especially for larger ring size. So clamp the size instead of returning an error. Do this in the core to avoid having each driver do the clamping. The current limit was deemed to high [1] so it was reduced to 16K to avoid page waste. [1] https://lore.kernel.org/all/1758532715-820422-3-git-send-email-tariqt@nvidia.com/ Signed-off-by: Dragos Tatulea Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250926131605.2276734-2-dtatulea@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2acf073edeb79c0069f9eb44ac8dd4943be2862e Author: Chi Zhiling Date: Fri Aug 15 17:32:45 2025 +0800 exfat: limit log print for IO error [ Upstream commit 6dfba108387bf4e71411b3da90b2d5cce48ba054 ] For exFAT filesystems with 4MB read_ahead_size, removing the storage device when the read operation is in progress, which cause the last read syscall spent 150s [1]. The main reason is that exFAT generates excessive log messages [2]. After applying this patch, approximately 300,000 lines of log messages were suppressed, and the delay of the last read() syscall was reduced to about 4 seconds. [1]: write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000120> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000032> write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000119> read(4, 0x7fccf28ae000, 131072) = -1 EIO (Input/output error) <150.186215> [2]: [ 333.696603] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) [ 333.697378] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) [ 333.698156] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) Signed-off-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c70926971b36b871abfe40e695d5b4966b62ef6f Author: Roy Vegard Ovesen Date: Sat Sep 27 17:27:30 2025 +0200 ALSA: usb-audio: add mono main switch to Presonus S1824c [ Upstream commit 659169c4eb21f8d9646044a4f4e1bc314f6f9d0c ] The 1824c does not have the A/B switch that the 1810c has, but instead it has a mono main switch that sums the two main output channels to mono. Signed-off-by: Roy Vegard Ovesen Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b65ca9708bfbf47d8b7bd44b7c574bd16798e9c9 Author: Ivan Pravdin Date: Sat Aug 30 16:03:40 2025 -0400 Bluetooth: bcsp: receive data only if registered [ Upstream commit ca94b2b036c22556c3a66f1b80f490882deef7a6 ] Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH. Reported-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4ed6852d4da4606c93da Tested-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com Signed-off-by: Ivan Pravdin Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d2850f037c2ae75882d68ae654d546ff5c0f678c Author: Luiz Augusto von Dentz Date: Mon Sep 22 13:13:13 2025 -0400 Bluetooth: SCO: Fix UAF on sco_conn_free [ Upstream commit ecb9a843be4d6fd710d7026e359f21015a062572 ] BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x1dd/0x240 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: cen zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d4d90a419b55e07384fc4d21382779a6772ebb75 Author: Théo Lebrun Date: Tue Sep 23 18:00:27 2025 +0200 net: macb: avoid dealing with endianness in macb_set_hwaddr() [ Upstream commit 70a5ce8bc94545ba0fb47b2498bfb12de2132f4d ] bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32 pointer and dereferencing implies dealing manually with endianness, which is error-prone. Replace by calls to get_unaligned_le32|le16() helpers. This was found using sparse: ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o warning: incorrect type in assignment (different base types) expected unsigned int [usertype] bottom got restricted __le32 [usertype] warning: incorrect type in assignment (different base types) expected unsigned short [usertype] top got restricted __le16 [usertype] ... Reviewed-by: Sean Anderson Signed-off-by: Théo Lebrun Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250923-macb-fixes-v6-5-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb7d0d13c6e1f061464d1c425b08348a4e0c235d Author: chuguangqing Date: Wed Aug 6 10:28:49 2025 +0800 fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock [ Upstream commit 1534f72dc2a11ded38b0e0268fbcc0ca24e9fd4a ] The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag. Signed-off-by: chuguangqing Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b2eef65a3be25974f66940497f7625999a9c2bdb Author: Alok Tiwari Date: Mon Sep 15 11:37:57 2025 -0700 scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill() [ Upstream commit 072fdd4b0be9b9051bdf75f36d0227aa705074ba ] The fc_ct_ms_fill() helper currently formats the OS name and version into entry->value using "%s v%s". Since init_utsname()->sysname and ->release are unbounded strings, snprintf() may attempt to write more than FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN bytes, triggering a -Wformat-truncation warning with W=1. In file included from drivers/scsi/libfc/fc_elsct.c:18: drivers/scsi/libfc/fc_encode.h: In function ‘fc_ct_ms_fill.constprop’: drivers/scsi/libfc/fc_encode.h:359:30: error: ‘%s’ directive output may be truncated writing up to 64 bytes into a region of size between 62 and 126 [-Werror=format-truncation=] 359 | "%s v%s", | ^~ 360 | init_utsname()->sysname, 361 | init_utsname()->release); | ~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/libfc/fc_encode.h:357:17: note: ‘snprintf’ output between 3 and 131 bytes into a destination of size 128 357 | snprintf((char *)&entry->value, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 358 | FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 359 | "%s v%s", | ~~~~~~~~~ 360 | init_utsname()->sysname, | ~~~~~~~~~~~~~~~~~~~~~~~~ 361 | init_utsname()->release); | ~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by using "%.62s v%.62s", which ensures sysname and release are truncated to fit within the 128-byte field defined by FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN. [mkp: clarified commit description] Signed-off-by: Alok Tiwari Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fa4daf7d11e45b72aad5d943a7ab991f869fff79 Author: Al Viro Date: Tue Sep 16 17:22:45 2025 +0100 nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ] Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that. Signed-off-by: Al Viro Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit a8a97e0d0b6020469ccada49820c3a1893a70333 Author: Anthony Iliopoulos Date: Wed Aug 13 11:00:47 2025 +0200 NFSv4.1: fix mount hang after CREATE_SESSION failure [ Upstream commit bf75ad096820fee5da40e671ebb32de725a1c417 ] When client initialization goes through server trunking discovery, it schedules the state manager and then sleeps waiting for nfs_client initialization completion. The state manager can fail during state recovery, and specifically in lease establishment as nfs41_init_clientid() will bail out in case of errors returned from nfs4_proc_create_session(), without ever marking the client ready. The session creation can fail for a variety of reasons e.g. during backchannel parameter negotiation, with status -EINVAL. The error status will propagate all the way to the nfs4_state_manager but the client status will not be marked, and thus the mount process will remain blocked waiting. Fix it by adding -EINVAL error handling to nfs4_state_manager(). Signed-off-by: Anthony Iliopoulos Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 679fd67bac26924969593040c48dc5289bde5f38 Author: Olga Kornievskaia Date: Mon Aug 11 14:18:48 2025 -0400 NFSv4: handle ERR_GRACE on delegation recalls [ Upstream commit be390f95242785adbf37d7b8a5101dd2f2ba891b ] RFC7530 states that clients should be prepared for the return of NFS4ERR_GRACE errors for non-reclaim lock and I/O requests. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit ca806ebc497bb7ebcba0c0310c08a3f8e9ee098b Author: Stephan Gerhold Date: Wed Aug 20 18:02:34 2025 +0200 remoteproc: qcom: q6v5: Avoid handling handover twice [ Upstream commit 54898664e1eb6b5b3e6cdd9343c6eb15da776153 ] A remoteproc could theoretically signal handover twice. This is unexpected and would break the reference counting for the handover resources (power domains, clocks, regulators, etc), so add a check to prevent that from happening. Reviewed-by: Dmitry Baryshkov Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-2-910b1a3aff71@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e50066336660ccc541e7ef7b684064c41d80d15c Author: Koakuma Date: Mon Jun 9 20:53:11 2025 +0700 sparc/module: Add R_SPARC_UA64 relocation handling [ Upstream commit 05457d96175d25c976ab6241c332ae2eb5e07833 ] This is needed so that the kernel can handle R_SPARC_UA64 relocations, which is emitted by LLVM's IAS. Signed-off-by: Koakuma Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit eb3d29ca0820fa3d7cccad47d2da56c9ab5469ed Author: Chen Wang Date: Fri Sep 12 10:36:01 2025 +0800 PCI: cadence: Check for the existence of cdns_pcie::ops before using it [ Upstream commit 49a6c160ad4812476f8ae1a8f4ed6d15adfa6c09 ] cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. Signed-off-by: Chen Wang [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com Signed-off-by: Sasha Levin commit c3f99fd7ed17d3fde9b8aff154c9b71942cf267a Author: ChunHao Lin Date: Thu Sep 18 10:34:25 2025 +0800 r8169: set EEE speed down ratio to 1 [ Upstream commit bf7154ffb1c65a201906296a9d3eb22e9daa5ffc ] EEE speed down means speed down MAC MCU clock. It is not from spec. It is kind of Realtek specific power saving feature. But enable it may cause some issues, like packet drop or interrupt loss. Different hardware may have different issues. EEE speed down ratio (mac ocp 0xe056[7:4]) is used to set EEE speed down rate. The larger this value is, the more power can save. But it actually save less power then we expected. And, as mentioned above, will impact compatibility. So set it to 1 (mac ocp 0xe056[7:4] = 0) , which means not to speed down, to improve compatibility. Signed-off-by: ChunHao Lin Reviewed-by: Heiner Kallweit Link: https://patch.msgid.link/20250918023425.3463-1-hau@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 826ad86e12708c53a7007e675302d062214a5079 Author: Brahmajit Das Date: Tue Sep 2 12:54:22 2025 +0530 net: intel: fm10k: Fix parameter idx set but not used [ Upstream commit 99e9c5ffbbee0f258a1da4eadf602b943f8c8300 ] Variable idx is set in the loop, but is never used resulting in dead code. Building with GCC 16, which enables -Werror=unused-but-set-parameter= by default results in build error. This patch removes the idx parameter, since all the callers of the fm10k_unbind_hw_stats_q as 0 as idx anyways. Suggested-by: Vadim Fedorenko Signed-off-by: Brahmajit Das Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit eb0c150d0279a42cae167bfb497059ca5a3a213c Author: Loic Poulain Date: Tue Sep 2 16:32:25 2025 +0200 wifi: ath10k: Fix connection after GTK rekeying [ Upstream commit 487e8a8c3421df0af3707e54c7e069f1d89cbda7 ] It appears that not all hardware/firmware implementations support group key deletion correctly, which can lead to connection hangs and deauthentication following GTK rekeying (delete and install). To avoid this issue, instead of attempting to delete the key using the special WMI_CIPHER_NONE value, we now replace the key with an invalid (random) value. This behavior has been observed with WCN39xx chipsets. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Reported-by: Alexey Klimov Closes: https://lore.kernel.org/all/DAWJQ2NIKY28.1XOG35E4A682G@linaro.org Signed-off-by: Loic Poulain Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Tested-by: Alexey Klimov # QRB2210 RB1 Link: https://patch.msgid.link/20250902143225.837487-1-loic.poulain@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0f7f342920716f298c365cecc79d33e41b39b853 Author: Seyediman Seyedarab Date: Thu Sep 18 13:01:58 2025 +0800 iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot() [ Upstream commit 75c02a037609f34db17e91be195cedb33b61bae0 ] snprintf() returns the number of bytes that would have been written, not the number actually written. Using this for offset tracking can cause buffer overruns if truncation occurs. Replace snprintf() with scnprintf() to ensure the offset stays within bounds. Since scnprintf() never returns a negative value, and zero is not possible in this context because 'bytes' starts at 0 and 'size - bytes' is DEBUG_BUFFER_SIZE in the first call, which is large enough to hold the string literals used, the return value is always positive. An integer overflow is also completely out of reach here due to the small and fixed buffer size. The error check in latency_show_one() is therefore unnecessary. Remove it and make dmar_latency_snapshot() return void. Signed-off-by: Seyediman Seyedarab Link: https://lore.kernel.org/r/20250731225048.131364-1-ImanDevel@gmail.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f878bfd2c14ce5b19bcd7e23b43f3ef61da0ab2b Author: Robert Marko Date: Wed Sep 17 13:00:24 2025 +0200 net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X [ Upstream commit 6287982aa54946449bccff3e6488d3a15e458392 ] LAN969x switchdev support depends on the SparX-5 core,so make it selectable for ARCH_LAN969X. Signed-off-by: Robert Marko Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20250917110106.55219-1-robert.marko@sartura.hr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2aa97cde9857f881920635a2e3d3b11769619c5 Author: Shaurya Rane Date: Mon Aug 25 01:43:32 2025 +0530 jfs: fix uninitialized waitqueue in transaction manager [ Upstream commit 300b072df72694ea330c4c673c035253e07827b8 ] The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit(). Reported-by: syzbot+c4f3462d8b2ad7977bea@syzkaller.appspotmail.com Signed-off-by: Shaurya Rane Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 46c76cfa17d1828c1a889cb54cb11d5ef3dfbc0f Author: Tetsuo Handa Date: Fri Sep 12 23:18:44 2025 +0900 jfs: Verify inode mode when loading from disk [ Upstream commit 7a5aa54fba2bd591b22b9b624e6baa9037276986 ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 14b6f0b3cfe20c38f542855f43e81e35d2fc65e6 Author: Eric Dumazet Date: Tue Sep 16 16:09:44 2025 +0000 ipv6: np->rxpmtu race annotation [ Upstream commit 9fba1eb39e2f74d2002c5cbcf1d4435d37a4f752 ] Add READ_ONCE() annotations because np->rxpmtu can be changed while udpv6_recvmsg() and rawv6_recvmsg() read it. Since this is a very rarely used feature, and that udpv6_recvmsg() and rawv6_recvmsg() read np->rxopt anyway, change the test order so that np->rxpmtu does not need to be in a hot cache line. Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: David Ahern Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250916160951.541279-4-edumazet@google.com Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 318aeeb3f8fef311277f7e48231de444436ea4cd Author: Krishna Kurapati Date: Tue Sep 16 17:34:36 2025 +0530 usb: xhci: plat: Facilitate using autosuspend for xhci plat devices [ Upstream commit 41cf11946b9076383a2222bbf1ef57d64d033f66 ] Allow autosuspend to be used by xhci plat device. For Qualcomm SoCs, when in host mode, it is intended that the controller goes to suspend state to save power and wait for interrupts from connected peripheral to wake it up. This is particularly used in cases where a HID or Audio device is connected. In such scenarios, the usb controller can enter auto suspend and resume action after getting interrupts from the connected device. Signed-off-by: Krishna Kurapati Link: https://lore.kernel.org/r/20250916120436.3617598-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7a219cbbc9e89eac7ba943be7c9dfed875eed5dd Author: Forest Crossman Date: Mon Sep 15 15:55:10 2025 -0400 usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs [ Upstream commit 368ed48a5ef52e384f54d5809f0a0b79ac567479 ] The usbmon binary interface currently truncates captures of large transfers from higher-speed USB devices. Because a single event capture is limited to one-fifth of the total buffer size, the current maximum size of a captured URB is around 240 KiB. This is insufficient when capturing traffic from modern devices that use transfers of several hundred kilobytes or more, as truncated URBs can make it impossible for user-space USB analysis tools like Wireshark to properly defragment and reassemble higher-level protocol packets in the captured data. The root cause of this issue is the 1200 KiB BUFF_MAX limit, which has not been changed since the binary interface was introduced in 2006. To resolve this issue, this patch increases BUFF_MAX to 64 MiB. The original comment for BUFF_MAX based the limit's calculation on a saturated 480 Mbit/s bus. Applying the same logic to a modern USB 3.2 Gen 2×2 20 Gbit/s bus (~2500 MB/s over a 20ms window) indicates the buffer should be at least 50 MB. The new limit of 64 MiB covers that, plus a little extra for any overhead. With this change, both users and developers should now be able to debug and reverse engineer modern USB devices even when running unmodified distro kernels. Please note that this change does not affect the default buffer size. A larger buffer is only allocated when a user explicitly requests it via the MON_IOCT_RING_SIZE ioctl, so the change to the maximum buffer size should not unduly increase memory usage for users that don't deliberately request a larger buffer. Link: https://lore.kernel.org/CAO3ALPzdUkmMr0YMrODLeDSLZqNCkWcAP8NumuPHLjNJ8wC1kQ@mail.gmail.com Signed-off-by: Forest Crossman Acked-by: Alan Stern Link: https://lore.kernel.org/r/CAO3ALPxU5RzcoueC454L=WZ1qGMfAcnxm+T+p+9D8O9mcrUbCQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 311df10cca0ecb2c48ca14f57442aa5544bf14ec Author: Al Viro Date: Fri Sep 12 11:20:27 2025 -0400 allow finish_no_open(file, ERR_PTR(-E...)) [ Upstream commit fe91e078b60d1beabf5cef4a37c848457a6d2dfb ] ... allowing any ->lookup() return value to be passed to it. Reviewed-by: NeilBrown Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit ffae0417168e69a6843f64e07244d426187b181f Author: Justin Tee Date: Mon Sep 15 11:08:05 2025 -0700 scsi: lpfc: Define size of debugfs entry for xri rebalancing [ Upstream commit 5de09770b1c0e229d2cec93e7f634fcdc87c9bc8 ] To assist in debugging lpfc_xri_rebalancing driver parameter, a debugfs entry is used. The debugfs file operations for xri rebalancing have been previously implemented, but lack definition for its information buffer size. Similar to other pre-existing debugfs entry buffers, define LPFC_HDWQINFO_SIZE as 8192 bytes. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-9-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 57225d17cd8d4f61f9ddc1e2ef8b1832ab1935c1 Author: Justin Tee Date: Mon Sep 15 11:08:01 2025 -0700 scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl in lpfc_cleanup [ Upstream commit a4809b98eb004fcbf7c4d45eb5a624d1c682bb73 ] In lpfc_cleanup, there is an extraneous nlp_put for NPIV ports on the F_Port_Ctrl ndlp object. In cases when an ABTS is issued, the outstanding kref is needed for when a second XRI_ABORTED CQE is received. The final kref for the ndlp is designed to be decremented in lpfc_sli4_els_xri_aborted instead. Also, add a new log message to allow for future diagnostics when debugging related issues. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-5-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 430e3ca0a53de4b991598366e7fe3fab0bc0ca8b Author: Justin Tee Date: Mon Sep 15 11:08:03 2025 -0700 scsi: lpfc: Check return status of lpfc_reset_flush_io_context during TGT_RESET [ Upstream commit f408dde2468b3957e92b25e7438f74c8e9fb9e73 ] If lpfc_reset_flush_io_context fails to execute, then the wrong return status code may be passed back to upper layers when issuing a target reset TMF command. Fix by checking the return status from lpfc_reset_flush_io_context() first in order to properly return FAILED or FAST_IO_FAIL. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-7-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 41cd00665c9936c8be4ca253c73ddfdbcbf9fa6b Author: Nai-Chen Cheng Date: Wed Sep 10 19:30:32 2025 +0800 selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to clean net/lib dependency [ Upstream commit d3f7457da7b9527a06dbcbfaf666aa51ac2eeb53 ] The selftests 'make clean' does not clean the net/lib because it only processes $(TARGETS) and ignores $(INSTALL_DEP_TARGETS). This leaves compiled objects in net/lib after cleaning, requiring manual cleanup. Include $(INSTALL_DEP_TARGETS) in clean target to ensure net/lib dependency is properly cleaned. Signed-off-by: Nai-Chen Cheng Reviewed-by: Simon Horman Tested-by: Simon Horman # build-tested Acked-by: Shuah Khan Link: https://patch.msgid.link/20250910-selftests-makefile-clean-v1-1-29e7f496cd87@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ec2cd5c58793d0c622797cd5fbe26634b357210 Author: Jakub Kicinski Date: Fri Sep 12 09:17:03 2025 -0700 page_pool: always add GFP_NOWARN for ATOMIC allocations [ Upstream commit f3b52167a0cb23b27414452fbc1278da2ee884fc ] Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default. Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250912161703.361272-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a58098c6b91cd15c82ea8fda84cbff4dde6194d5 Author: Tvrtko Ursulin Date: Thu Jun 12 11:44:27 2025 +0100 drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl [ Upstream commit dea75df7afe14d6217576dbc28cc3ec1d1f712fb ] Replace kmalloc_array() + copy_from_user() with memdup_array_user(). This shrinks the source code and improves separation between the kernel and userspace slabs. Signed-off-by: Tvrtko Ursulin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fd62e1a94cff40cd7efb9a9ac0cbe4d5a7ff19f0 Author: Yafang Shao Date: Tue Sep 2 14:29:33 2025 +0800 net/cls_cgroup: Fix task_get_classid() during qdisc run [ Upstream commit 66048f8b3cc7e462953c04285183cdee43a1cb89 ] During recent testing with the netem qdisc to inject delays into TCP traffic, we observed that our CLS BPF program failed to function correctly due to incorrect classid retrieval from task_get_classid(). The issue manifests in the following call stack: bpf_get_cgroup_classid+5 cls_bpf_classify+507 __tcf_classify+90 tcf_classify+217 __dev_queue_xmit+798 bond_dev_queue_xmit+43 __bond_start_xmit+211 bond_start_xmit+70 dev_hard_start_xmit+142 sch_direct_xmit+161 __qdisc_run+102 <<<<< Issue location __dev_xmit_skb+1015 __dev_queue_xmit+637 neigh_hh_output+159 ip_finish_output2+461 __ip_finish_output+183 ip_finish_output+41 ip_output+120 ip_local_out+94 __ip_queue_xmit+394 ip_queue_xmit+21 __tcp_transmit_skb+2169 tcp_write_xmit+959 __tcp_push_pending_frames+55 tcp_push+264 tcp_sendmsg_locked+661 tcp_sendmsg+45 inet_sendmsg+67 sock_sendmsg+98 sock_write_iter+147 vfs_write+786 ksys_write+181 __x64_sys_write+25 do_syscall_64+56 entry_SYSCALL_64_after_hwframe+100 The problem occurs when multiple tasks share a single qdisc. In such cases, __qdisc_run() may transmit skbs created by different tasks. Consequently, task_get_classid() retrieves an incorrect classid since it references the current task's context rather than the skb's originating task. Given that dev_queue_xmit() always executes with bh disabled, we can use softirq_count() instead to obtain the correct classid. The simple steps to reproduce this issue: 1. Add network delay to the network interface: such as: tc qdisc add dev bond0 root netem delay 1.5ms 2. Build two distinct net_cls cgroups, each with a network-intensive task 3. Initiate parallel TCP streams from both tasks to external servers. Under this specific condition, the issue reliably occurs. The kernel eventually dequeues an SKB that originated from Task-A while executing in the context of Task-B. It is worth noting that it will change the established behavior for a slightly different scenario: prior to this patch the skb will be classified with the 'new' task A classid, now with the old/original one. The bpf_get_cgroup_classid_curr() function is a more appropriate choice for this case. Signed-off-by: Yafang Shao Cc: Daniel Borkmann Cc: Thomas Graf Cc: Sebastian Andrzej Siewior Cc: Nikolay Aleksandrov Link: https://patch.msgid.link/20250902062933.30087-1-laoar.shao@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45e4e4a8772fa1c5f6f38e82b732b3a9d8137af4 Author: Alok Tiwari Date: Wed Sep 10 12:50:26 2025 -0700 udp_tunnel: use netdev_warn() instead of netdev_WARN() [ Upstream commit dc2f650f7e6857bf384069c1a56b2937a1ee370d ] netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly. Signed-off-by: Alok Tiwari Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250910195031.3784748-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d276a6c3bb74c37c7d001c8bb8d21450796f8aa2 Author: David Ahern Date: Tue Sep 9 20:58:28 2025 -0600 selftests: Replace sleep with slowwait [ Upstream commit 2f186dd5585c3afb415df80e52f71af16c9d3655 ] Replace the sleep in kill_procs with slowwait. Signed-off-by: David Ahern Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250910025828.38900-2-dsahern@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbf410aafc85177118f78c17c27889d623008ee8 Author: Daniel Palmer Date: Sun Sep 7 15:43:49 2025 +0900 eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP [ Upstream commit 43adad382e1fdecabd2c4cd2bea777ef4ce4109e ] When 8139too is probing and 8139TOO_PIO=y it will call pci_iomap_range() and from there __pci_ioport_map() for the PCI IO space. If HAS_IOPORT_MAP=n and NO_GENERIC_PCI_IOPORT_MAP=n, like it is on my m68k config, __pci_ioport_map() becomes NULL, pci_iomap_range() will always fail and the driver will complain it couldn't map the PIO space and return an error. NO_IOPORT_MAP seems to cover the case where what 8139too is trying to do cannot ever work so make 8139TOO_PIO depend on being it false and avoid creating an unusable driver. Signed-off-by: Daniel Palmer Link: https://patch.msgid.link/20250907064349.3427600-1-daniel@thingy.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff4cd9564dc3adba8af0374785ca2501ef92250a Author: David Ahern Date: Tue Sep 9 20:58:27 2025 -0600 selftests: Disable dad for ipv6 in fcnal-test.sh [ Upstream commit 53d591730ea34f97a82f7ec6e7c987ca6e34dc21 ] Constrained test environment; duplicate address detection is not needed and causes races so disable it. Signed-off-by: David Ahern Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250910025828.38900-1-dsahern@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b16a010338bf1dbce527b59af1b003605da8701c Author: Li RongQing Date: Tue Jul 22 19:00:05 2025 +0800 x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of PV_UNHALT [ Upstream commit 960550503965094b0babd7e8c83ec66c8a763b0b ] The commit b2798ba0b876 ("KVM: X86: Choose qspinlock when dedicated physical CPUs are available") states that when PV_DEDICATED=1 (vCPU has dedicated pCPU), qspinlock should be preferred regardless of PV_UNHALT. However, the current implementation doesn't reflect this: when PV_UNHALT=0, we still use virt_spin_lock() even with dedicated pCPUs. This is suboptimal because: 1. Native qspinlocks should outperform virt_spin_lock() for dedicated vCPUs irrespective of HALT exiting 2. virt_spin_lock() should only be preferred when vCPUs may be preempted (non-dedicated case) So reorder the PV spinlock checks to: 1. First handle dedicated pCPU case (disable virt_spin_lock_key) 2. Second check single CPU, and nopvspin configuration 3. Only then check PV_UNHALT support This ensures we always use native qspinlock for dedicated vCPUs, delivering pretty performance gains at high contention levels. Signed-off-by: Li RongQing Reviewed-by: Sean Christopherson Tested-by: Wangyang Guo Link: https://lore.kernel.org/r/20250722110005.4988-1-lirongqing@baidu.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 56c832864e5e8424de7e5340cc2285258ede1672 Author: Florian Westphal Date: Fri Aug 29 17:01:02 2025 +0200 netfilter: nf_reject: don't reply to icmp error messages [ Upstream commit db99b2f2b3e2cd8227ac9990ca4a8a31a1e95e56 ] tcp reject code won't reply to a tcp reset. But the icmp reject 'netdev' family versions will reply to icmp dst-unreach errors, unlike icmp_send() and icmp6_send() which are used by the inet family implementation (and internally by the REJECT target). Check for the icmp(6) type and do not respond if its an unreachable error. Without this, something like 'ip protocol icmp reject', when used in a netdev chain attached to 'lo', cause a packet loop. Same for two hosts that both use such a rule: each error packet will be replied to. Such situation persist until the (bogus) rule is amended to ratelimit or checks the icmp type before the reject statement. As the inet versions don't do this make the netdev ones follow along. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 0858b8e38884f5e40b438f080c9cff732f2ffd57 Author: Ido Schimmel Date: Mon Sep 8 10:32:35 2025 +0300 selftests: traceroute: Use require_command() [ Upstream commit 47efbac9b768553331b9459743a29861e0acd797 ] Use require_command() so that the test will return SKIP (4) when a required command is not present. Before: # ./traceroute.sh SKIP: Could not run IPV6 test without traceroute6 SKIP: Could not run IPV4 test without traceroute $ echo $? 0 After: # ./traceroute.sh TEST: traceroute6 not installed [SKIP] $ echo $? 4 Reviewed-by: Petr Machata Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250908073238.119240-6-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9d2e3da0a0e8428501c6ab0851510c294f6ac0a8 Author: Qianfeng Rong Date: Wed Aug 27 20:39:13 2025 +0800 media: redrat3: use int type to store negative error codes [ Upstream commit ecba852dc9f4993f4f894ea1f352564560e19a3e ] Change "ret" from u8 to int type in redrat3_enable_detector() to store negative error codes or zero returned by redrat3_send_cmd() and usb_submit_urb() - this better aligns with the coding standards and maintains code consistency. No effect on runtime. Signed-off-by: Qianfeng Rong Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ffb663e41ddec0f69d5a030fc2cf3c5e2f855325 Author: Niklas Söderlund Date: Tue Sep 9 10:58:49 2025 +0200 net: sh_eth: Disable WoL if system can not suspend [ Upstream commit 9c02ea544ac35a9def5827d30594406947ccd81a ] The MAC can't facilitate WoL if the system can't go to sleep. Gate the WoL support callbacks in ethtool at compile time using CONFIG_PM_SLEEP. Signed-off-by: Niklas Söderlund Reviewed-by: Andrew Lunn Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250909085849.3808169-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eab8d5e5e1d0719139044e930dc940412ab6c7b1 Author: Michael Riesch Date: Wed Sep 3 19:04:52 2025 +0200 phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0 [ Upstream commit 8c7c19466c854fa86b82d2148eaa9bf0e6531423 ] The driver for the Rockchip MIPI CSI-2 DPHY uses GRF register offset value 0 to sort out undefined registers. However, the RK3588 CSIDPHY GRF this offset is perfectly fine (in fact, register 0 is the only one in this register file). Introduce a boolean variable to indicate valid registers and allow writes to register 0. Reviewed-by: Neil Armstrong Signed-off-by: Michael Riesch Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-4-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 04f057e4c15693f4cef190634cb158fc675d92ee Author: Harikrishna Shenoy Date: Thu Aug 7 10:50:02 2025 +0530 phy: cadence: cdns-dphy: Enable lower resolutions in dphy [ Upstream commit 43bd2c44515f8ee5c019ce6e6583f5640387a41b ] Enable support for data lane rates between 80-160 Mbps cdns dphy as mentioned in TRM [0] by setting the pll_opdiv field to 16. This change enables lower resolutions like 640x480 at 60Hz. [0]: https://www.ti.com/lit/zip/spruil1 (Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions) Reviewed-by: Udit Kumar Reviewed-by: Devarsh Thakkar Signed-off-by: Harikrishna Shenoy Link: https://lore.kernel.org/r/20250807052002.717807-1-h-shenoy@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 63eb6730ce0604d3eacf036c2f68ea70b068317c Author: Tetsuo Handa Date: Tue Sep 2 19:43:24 2025 +0900 ntfs3: pretend $Extend records as regular files [ Upstream commit 4e8011ffec79717e5fdac43a7e79faf811a384b7 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 8a8d0755358342623f4017747d23cceede1bffd1 Author: Rohan G Thomas Date: Sat Sep 6 10:33:31 2025 +0800 net: phy: marvell: Fix 88e1510 downshift counter errata [ Upstream commit deb105f49879dd50d595f7f55207d6e74dec34e6 ] The 88e1510 PHY has an erratum where the phy downshift counter is not cleared after phy being suspended(BMCR_PDOWN set) and then later resumed(BMCR_PDOWN cleared). This can cause the gigabit link to intermittently downshift to a lower speed. Disabling and re-enabling the downshift feature clears the counter, allowing the PHY to retry gigabit link negotiation up to the programmed retry count times before downshifting. This behavior has been observed on copper links. Signed-off-by: Rohan G Thomas Reviewed-by: Matthew Gerlach Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250906-marvell_fix-v2-1-f6efb286937f@altera.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f30019f5a58aac0e397d32e5f61fbef831436d4 Author: Antonino Maniscalco Date: Thu Aug 21 15:06:34 2025 +0200 drm/msm: make sure to not queue up recovery more than once [ Upstream commit 10fb1b2fcaee5545a5e54db1ed4d7b15c2db50c8 ] If two fault IRQs arrive in short succession recovery work will be queued up twice. When recovery runs a second time it may end up killing an unrelated context. Prevent this by masking off interrupts when triggering recovery. Signed-off-by: Antonino Maniscalco Reviewed-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/670023/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0cf9a50af91fbdac3849f8d950e883a3eaa3ecea Author: Chen Yufeng Date: Fri Sep 5 17:48:42 2025 +0800 usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget [ Upstream commit 87c5ff5615dc0a37167e8faf3adeeddc6f1344a3 ] In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints"). Signed-off-by: Chen Yufeng Link: https://lore.kernel.org/r/20250905094842.1232-1-chenyufeng@iie.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2dc7bcc0b1123bfb6f8e78d76dd7f75b880b4587 Author: William Wu Date: Tue Aug 26 18:28:07 2025 +0800 usb: gadget: f_hid: Fix zero length packet transfer [ Upstream commit ed6f727c575b1eb8136e744acfd5e7306c9548f6 ] Set the hid req->zero flag of ep0/in_ep to true by default, then the UDC drivers can transfer a zero length packet at the end if the hid transfer with size divisible to EPs max packet size according to the USB 2.0 spec. Signed-off-by: William Wu Link: https://lore.kernel.org/r/1756204087-26111-1-git-send-email-william.wu@rock-chips.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bb8f9de71c9bd442ec5e1d52ce830428860892f0 Author: Ashish Kalra Date: Mon Aug 25 21:46:53 2025 +0000 iommu/amd: Skip enabling command/event buffers for kdump [ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ] After a panic if SNP is enabled in the previous kernel then the kdump kernel boots with IOMMU SNP enforcement still enabled. IOMMU command buffers and event buffer registers remain locked and exclusive to the previous kernel. Attempts to enable command and event buffers in the kdump kernel will fail, as hardware ignores writes to the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1. Skip enabling command buffers and event buffers for kdump boot as they are already enabled in the previous kernel. Reviewed-by: Vasant Hegde Tested-by: Sairaj Kodilkar Signed-off-by: Ashish Kalra Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 66bcd6c577d83d0db60468d04e3c8c79caa649ce Author: Eric Dumazet Date: Wed Sep 3 17:48:10 2025 +0000 net: call cond_resched() less often in __release_sock() [ Upstream commit 16c610162d1f1c332209de1c91ffb09b659bb65d ] While stress testing TCP I had unexpected retransmits and sack packets when a single cpu receives data from multiple high-throughput flows. super_netperf 4 -H srv -T,10 -l 3000 & Tcpdump extract: 00:00:00.000007 IP6 clnt > srv: Flags [.], seq 26062848:26124288, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26124288:26185728, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26185728:26243072, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 57344 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26243072:26304512, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26304512:26365952, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440 00:00:00.000007 IP6 clnt > srv: Flags [P.], seq 26365952:26423296, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 57344 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26423296:26484736, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26484736:26546176, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26546176:26603520, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 57344 00:00:00.003932 IP6 clnt > srv: Flags [P.], seq 26603520:26619904, ack 1, win 66, options [nop,nop,TS val 651464844 ecr 3100753141], length 16384 00:00:00.006602 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651471419 ecr 3100759716], length 4096 00:00:00.013000 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651484421 ecr 3100772718], length 4096 00:00:00.000416 IP6 srv > clnt: Flags [.], ack 26619904, win 1393, options [nop,nop,TS val 3100773185 ecr 651484421,nop,nop,sack 1 {24862720:24866816}], length 0 After analysis, it appears this is because of the cond_resched() call from __release_sock(). When current thread is yielding, while still holding the TCP socket lock, it might regain the cpu after a very long time. Other peer TLP/RTO is firing (multiple times) and packets are retransmit, while the initial copy is waiting in the socket backlog or receive queue. In this patch, I call cond_resched() only once every 16 packets. Modern TCP stack now spends less time per packet in the backlog, especially because ACK are no longer sent (commit 133c4c0d3717 "tcp: defer regular ACK while processing socket backlog") Before: clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK" TcpOutSegs 19046186 0.0 TcpRetransSegs 1471 0.0 TcpExtTCPTimeouts 1397 0.0 TcpExtTCPLossProbes 1356 0.0 TcpExtTCPDSACKRecv 1352 0.0 TcpExtTCPSpuriousRTOs 114 0.0 TcpExtTCPDSACKRecvSegs 1352 0.0 After: clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK" TcpOutSegs 19218936 0.0 Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250903174811.1930820-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07ae8cc64557c18c47dbaea5c062a0f3121cf81e Author: Juraj Šarinay Date: Tue Sep 2 13:36:28 2025 +0200 net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms [ Upstream commit 21f82062d0f241e55dd59eb630e8710862cc90b4 ] An exchange with a NFC target must complete within NCI_DATA_TIMEOUT. A delay of 700 ms is not sufficient for cryptographic operations on smart cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH or 3072-bit RSA. To prevent brute-force attacks, passports and similar documents introduce even longer delays into access control protocols (BAC/PACE). The timeout should be higher, but not too much. The expiration allows us to detect that a NFC target has disappeared. Signed-off-by: Juraj Šarinay Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250902113630.62393-1-juraj@sarinay.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fdfd91ac1f4438541e2b121717bce21b5de3bf87 Author: Yue Haibing Date: Mon Sep 1 20:37:26 2025 +0800 ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled [ Upstream commit 3d95261eeb74958cd496e1875684827dc5d028cc ] In ipv6_rpl_srh_rcv() we use min(net->ipv6.devconf_all->rpl_seg_enabled, idev->cnf.rpl_seg_enabled) is intended to return 0 when either value is zero, but if one of the values is negative it will in fact return non-zero. Signed-off-by: Yue Haibing Link: https://patch.msgid.link/20250901123726.1972881-3-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1452d49956d9769d8a1b1b90ba618bdbd5b69c22 Author: Krzysztof Kozlowski Date: Tue Jun 10 16:05:47 2025 +0200 drm/msm/dsi/phy_7nm: Fix missing initial VCO rate [ Upstream commit 5ddcb0cb9d10e6e70a68e0cb8f0b8e3a7eb8ccaf ] Driver unconditionally saves current state on first init in dsi_pll_7nm_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_7nm_pll_restore_state(). Restoring calls dsi_pll_7nm_vco_set_rate() with pll_7nm->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. Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Patchwork: https://patchwork.freedesktop.org/patch/657827/ Link: https://lore.kernel.org/r/20250610-b4-sm8750-display-v6-9-ee633e3ddbff@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit b4a4bf4b4452b662474d4006a5926c3e8e8ac217 Author: Krzysztof Kozlowski Date: Tue Jun 10 16:05:44 2025 +0200 drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL [ Upstream commit b63f008f395ca5f6bc89123db97440bdc19981c4 ] According to Hardware Programming Guide for DSI PHY, the retime buffer resync should be done after PLL clock users (byte_clk and intf_byte_clk) are enabled. Downstream also does it as part of configuring the PLL. Driver was only turning off the resync FIFO buffer, but never bringing it on again. Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Patchwork: https://patchwork.freedesktop.org/patch/657823/ Link: https://lore.kernel.org/r/20250610-b4-sm8750-display-v6-6-ee633e3ddbff@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit bda8e00b354a5b232032b341d4c874048c0142f7 Author: Devendra K Verma Date: Thu Aug 21 17:45:05 2025 +0530 dmaengine: dw-edma: Set status for callback_result [ Upstream commit 5e742de97c806a4048418237ef1283e7d71eaf4b ] DMA Engine has support for the callback_result which provides the status of the request and the residue. This helps in determining the correct status of the request and in efficient resource management of the request. The 'callback_result' method is preferred over the deprecated 'callback' method. Signed-off-by: Devendra K Verma Link: https://lore.kernel.org/r/20250821121505.318179-1-devverma@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 35e42324c21f7a0454d4a01e7908a72974ba1e49 Author: Rosen Penev Date: Thu Aug 21 15:09:42 2025 -0700 dmaengine: mv_xor: match alloc_wc and free_wc [ Upstream commit a33e3b667d2f004fdfae6b442bd4676f6c510abb ] dma_alloc_wc is used but not dma_free_wc. Signed-off-by: Rosen Penev Link: https://lore.kernel.org/r/20250821220942.10578-1-rosenp@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e12a50e3621f75566386e6dd93adaaa5445e0ce0 Author: Thomas Andreatta Date: Wed Aug 27 17:24:43 2025 +0200 dmaengine: sh: setup_xref error handling [ Upstream commit d9a3e9929452780df16f3414f0d59b5f69d058cf ] This patch modifies the type of setup_xref from void to int and handles errors since the function can fail. `setup_xref` now returns the (eventual) error from `dmae_set_dmars`|`dmae_set_chcr`, while `shdma_tx_submit` handles the result, removing the chunks from the queue and marking PM as idle in case of an error. Signed-off-by: Thomas Andreatta Link: https://lore.kernel.org/r/20250827152442.90962-1-thomas.andreatta2000@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 774e8d44ac88fb58db6b12a59c5428cb8b2c943f Author: Miroslav Lichvar Date: Thu Aug 28 12:32:53 2025 +0200 ptp: Limit time setting of PTP clocks [ Upstream commit 5a8c02a6bf52b1cf9cfb7868a8330f7c3c6aebe9 ] Networking drivers implementing PTP clocks and kernel socket code handling hardware timestamps use the 64-bit signed ktime_t type counting nanoseconds. When a PTP clock reaches the maximum value in year 2262, the timestamps returned to applications will overflow into year 1667. The same thing happens when injecting a large offset with clock_adjtime(ADJ_SETOFFSET). The commit 7a8e61f84786 ("timekeeping: Force upper bound for setting CLOCK_REALTIME") limited the maximum accepted value setting the system clock to 30 years before the maximum representable value (i.e. year 2232) to avoid the overflow, assuming the system will not run for more than 30 years. Enforce the same limit for PTP clocks. Don't allow negative values and values closer than 30 years to the maximum value. Drivers may implement an even lower limit if the hardware registers cannot represent the whole interval between years 1970 and 2262 in the required resolution. Signed-off-by: Miroslav Lichvar Cc: Richard Cochran Cc: Thomas Gleixner Cc: John Stultz Cc: Arnd Bergmann Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250828103300.1387025-1-mlichvar@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48c1d49c64d03fe84533d45c007a8e22debdb6cb Author: Qianfeng Rong Date: Tue Aug 26 17:32:42 2025 +0800 scsi: pm8001: Use int instead of u32 to store error codes [ Upstream commit bee3554d1a4efbce91d6eca732f41b97272213a5 ] Use int instead of u32 for 'ret' variable to store negative error codes returned by PM8001_CHIP_DISP->set_nvmd_req(). Signed-off-by: Qianfeng Rong Link: https://lore.kernel.org/r/20250826093242.230344-1-rongqianfeng@vivo.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7ce10ef9a9b6d8dc776c7d6550fc4f875bd015b4 Author: Aleksander Jan Bajkowski Date: Fri Aug 15 14:12:23 2025 +0200 mips: lantiq: xway: sysctrl: rename stp clock [ Upstream commit b0d04fe6a633ada2c7bc1b5ddd011cbd85961868 ] Bindig requires a node name matching ‘^gpio@[0-9a-f]+$’. This patch changes the clock name from “stp” to “gpio”. Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e1f79a12bd625c9f21e368fb1afe243eb924f320 Author: Aleksander Jan Bajkowski Date: Mon Aug 11 15:34:13 2025 +0200 mips: lantiq: danube: add missing device_type in pci node [ Upstream commit d66949a1875352d2ddd52b144333288952a9e36f ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: pci@e105400 (lantiq,pci-xway): 'device_type' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml# Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit a39c88bedb0f85313de95f391a79e1f21ea8974c Author: Aleksander Jan Bajkowski Date: Mon Aug 11 13:58:15 2025 +0200 mips: lantiq: danube: add missing properties to cpu node [ Upstream commit e8dee66c37085dc9858eb8608bc783c2900e50e7 ] This fixes the following warnings: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#address-cells' is a required property from schema $id: http://devicetree.org/schemas/cpus.yaml# arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#size-cells' is a required property from schema $id: http://devicetree.org/schemas/cpus.yaml# arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpu@0 (mips,mips24Kc): 'reg' is a required property from schema $id: http://devicetree.org/schemas/mips/cpus.yaml# Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 69f04cdd1a5080e0c03892beb8b74e400030b216 Author: Chelsy Ratnawat Date: Wed Aug 6 23:09:36 2025 -0700 media: fix uninitialized symbol warnings [ Upstream commit b4c441310c3baaa7c39a5457e305ca93c7a0400d ] Initialize variables to fix these smatch warnings drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'protocol'. drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'scancode'. drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'toggle'. drivers/media/tuners/xc4000.c:1102 xc_debug_dump() error: uninitialized symbol 'adc_envelope'. drivers/media/tuners/xc4000.c:1108 xc_debug_dump() error: uninitialized symbol 'lock_status'. drivers/media/tuners/xc4000.c:1123 xc_debug_dump() error: uninitialized symbol 'frame_lines'. drivers/media/tuners/xc4000.c:1127 xc_debug_dump() error: uninitialized symbol 'quality'. drivers/media/tuners/xc5000.c:645 xc_debug_dump() error: uninitialized symbol 'adc_envelope'. drivers/media/tuners/xc5000.c:651 xc_debug_dump() error: uninitialized symbol 'lock_status'. drivers/media/tuners/xc5000.c:665 xc_debug_dump() error: uninitialized symbol 'frame_lines'. drivers/media/tuners/xc5000.c:668 xc_debug_dump() error: uninitialized symbol 'quality'. drivers/media/tuners/xc5000.c:671 xc_debug_dump() error: uninitialized symbol 'snr'. drivers/media/tuners/xc5000.c:674 xc_debug_dump() error: uninitialized symbol 'totalgain'. Signed-off-by: Chelsy Ratnawat Signed-off-by: Hans Verkuil [hverkuil: dropped ' = 0' from rc in ir-kbd-i2c.c, not needed] Signed-off-by: Sasha Levin commit b751b7f87acb5e6155ed80472680aedfd184420a Author: Amber Lin Date: Fri Aug 15 14:04:15 2025 -0400 drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption [ Upstream commit f3820e9d356132e18405cd7606e22dc87ccfa6d1 ] When KFD asks CP to preempt queues, other than preempt CP queues, CP also requests SDMA to preempt SDMA queues with UNMAP_LATENCY timeout. Currently queue_preemption_timeout_ms is 9000 ms by default but can be configured via module parameter. KFD_UNMAP_LATENCY_MS is hard coded as 4000 ms though. This patch ties KFD_UNMAP_LATENCY_MS to queue_preemption_timeout_ms so in a slow system such as emulator, both CP and SDMA slowness are taken into account. Signed-off-by: Amber Lin Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 92071a422131b1765f2fd751acf8bc8b830dabad Author: Krzysztof Kozlowski Date: Thu May 1 16:33:21 2025 +0200 extcon: adc-jack: Fix wakeup source leaks on device unbind [ Upstream commit 78b6a991eb6c6f19ed7d0ac91cda3b3b117fda8f ] Device can be unbound, so driver must also release memory for the wakeup source. Do not use devm interface, because it would change the order of cleanup. Link: https://lore.kernel.org/lkml/20250501-device-wakeup-leak-extcon-v2-1-7af77802cbea@linaro.org/ Acked-by: MyungJoo Ham Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 62443e7d827a35173e9fce789d36e03d877232ab Author: Francisco Gutierrez Date: Wed Jul 23 18:35:43 2025 +0000 scsi: pm80xx: Fix race condition caused by static variables [ Upstream commit d6477ee38ccfbeaed885733c13f41d9076e2f94a ] Eliminate the use of static variables within the log pull implementation to resolve a race condition and prevent data gaps when pulling logs from multiple controllers in parallel, ensuring each operation is properly isolated. Signed-off-by: Francisco Gutierrez Link: https://lore.kernel.org/r/20250723183543.1443301-1-frankramirez@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 866d93632daa75628e3fee569ad2e0f4c82435d0 Author: Chandrakanth Patil Date: Wed Aug 20 14:11:34 2025 +0530 scsi: mpi3mr: Fix controller init failure on fault during queue creation [ Upstream commit 829fa1582b6ff607b0e2fe41ba1c45c77f686618 ] Firmware can enter a transient fault while creating operational queues. The driver fails the load immediately. Add a retry loop that checks controller status and history bit after queue creation. If either indicates a fault, retry init up to a set limit before failing. Signed-off-by: Chandrakanth Patil Link: https://lore.kernel.org/r/20250820084138.228471-3-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9650cd59f4e1824e0af74e849ddcde82c30d39d3 Author: Ujwal Kundur Date: Wed Aug 20 23:25:49 2025 +0530 rds: Fix endianness annotation for RDS_MPATH_HASH [ Upstream commit 77907a068717fbefb25faf01fecca553aca6ccaa ] jhash_1word accepts host endian inputs while rs_bound_port is a be16 value (sockaddr_in6.sin6_port). Use ntohs() for consistency. Flagged by Sparse. Signed-off-by: Ujwal Kundur Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20250820175550.498-4-ujwal.kundur@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb4f59e66952114437e205b296d826f6b2df92a1 Author: Takashi Iwai Date: Thu Aug 21 17:17:50 2025 +0200 ALSA: usb-audio: Add validation of UAC2/UAC3 effect units [ Upstream commit 2aec0b6a6b5395bca7d6fde9c7e9dc391d329698 ] Just add fixed struct size validations for UAC2 and UAC3 effect units. The descriptor has a variable-length array, so it should be validated with a proper function later once when the unit is really parsed and used by the driver (currently only referred partially for the input terminal parsing). Link: https://patch.msgid.link/20250821151751.12100-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 30cc10a05b2256394334ce9c5616fd2b11665138 Author: Sungho Kim Date: Wed Aug 20 19:57:14 2025 +0900 PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call [ Upstream commit 6238784e502b6a9fbeb3a6b77284b29baa4135cc ] The error handling path in pci_p2pdma_add_resource() contains a bug in its `pgmap_free` label. Memory is allocated for the `p2p_pgmap` struct, and the pointer is stored in `p2p_pgmap`. However, the error path calls devm_kfree() with `pgmap`, which is a pointer to a member field within the `p2p_pgmap` struct, not the base pointer of the allocation. Correct the bug by passing the correct base pointer, `p2p_pgmap`, to devm_kfree(). Signed-off-by: Sungho Kim Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Link: https://patch.msgid.link/20250820105714.2939896-1-sungho.kim@furiosa.ai Signed-off-by: Sasha Levin commit 38edfa2a5a7a699bfdc2837d6a15e0cf0e6d435a Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:12 2025 +0000 net: Call trace_sock_exceed_buf_limit() for memcg failure with SK_MEM_RECV. [ Upstream commit 9d85c565a7b7c78b732393c02bcaa4d5c275fe58 ] Initially, trace_sock_exceed_buf_limit() was invoked when __sk_mem_raise_allocated() failed due to the memcg limit or the global limit. However, commit d6f19938eb031 ("net: expose sk wmem in sock_exceed_buf_limit tracepoint") somehow suppressed the event only when memcg failed to charge for SK_MEM_RECV, although the memcg failure for SK_MEM_SEND still triggers the event. Let's restore the event for SK_MEM_RECV. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-5-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f80a71a29f2d98a476d02fa24a1d9f1fac96ade8 Author: Christoph Paasch Date: Sat Aug 16 16:12:49 2025 -0700 net: When removing nexthops, don't call synchronize_net if it is not necessary [ Upstream commit b0ac6d3b56a2384db151696cfda2836a8a961b6d ] When removing a nexthop, commit 90f33bffa382 ("nexthops: don't modify published nexthop groups") added a call to synchronize_rcu() (later changed to _net()) to make sure everyone sees the new nexthop-group before the rtnl-lock is released. When one wants to delete a large number of groups and nexthops, it is fastest to first flush the groups (ip nexthop flush groups) and then flush the nexthops themselves (ip -6 nexthop flush). As that way the groups don't need to be rebalanced. However, `ip -6 nexthop flush` will still take a long time if there is a very large number of nexthops because of the call to synchronize_net(). Now, if there are no more groups, there is no point in calling synchronize_net(). So, let's skip that entirely by checking if nh->grp_list is empty. This gives us a nice speedup: BEFORE: ======= $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 2097152 nexthops real 1m45.345s user 0m0.001s sys 0m0.005s $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 4194304 nexthops real 3m10.430s user 0m0.002s sys 0m0.004s AFTER: ====== $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 2097152 nexthops real 0m17.545s user 0m0.003s sys 0m0.003s $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 4194304 nexthops real 0m35.823s user 0m0.002s sys 0m0.004s Signed-off-by: Christoph Paasch Reviewed-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250816-nexthop_dump-v2-2-491da3462118@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2ee1c7fc9c22cfd24a1fbc57acfc8a3b8037250 Author: Zijun Hu Date: Mon Jul 14 23:34:17 2025 +0800 char: misc: Does not request module for miscdevice with dynamic minor [ Upstream commit 1ba0fb42aa6a5f072b1b8c0b0520b32ad4ef4b45 ] misc_open() may request module for miscdevice with dynamic minor, which is meaningless since: - The dynamic minor allocated is unknown in advance without registering miscdevice firstly. - Macro MODULE_ALIAS_MISCDEV() is not applicable for dynamic minor. Fix by only requesting module for miscdevice with fixed minor. Acked-by: Thadeu Lima de Souza Cascardo Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250714-rfc_miscdev-v6-6-2ed949665bde@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e14d3af189de740b8ab81ddcd35ddc424e2e2b16 Author: raub camaioni Date: Fri Aug 15 09:07:21 2025 -0400 usb: gadget: f_ncm: Fix MAC assignment NCM ethernet [ Upstream commit 956606bafb5fc6e5968aadcda86fc0037e1d7548 ] This fix is already present in f_ecm.c and was never propagated to f_ncm.c When creating multiple NCM ethernet devices on a composite usb gadget device each MAC address on the HOST side will be identical. Having the same MAC on different network interfaces is bad. This fix updates the MAC address inside the ncm_strings_defs global during the ncm_bind call. This ensures each device has a unique MAC. In f_ecm.c ecm_string_defs is updated in the same way. The defunct MAC assignment in ncm_alloc has been removed. Signed-off-by: raub camaioni Link: https://lore.kernel.org/r/20250815131358.1047525-1-raubcameo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f979f913b99c1162d188a6d05fc207316cda20a0 Author: Rodrigo Gobbi Date: Thu Jul 17 19:13:49 2025 -0300 iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before setting register [ Upstream commit d75c7021c08e8ae3f311ef2464dca0eaf75fab9f ] avg sample info is a bit field coded inside the following bits: 5,6,7 and 8 of a device status register. Channel num info the same, but over bits: 1, 2 and 3. Mask both values in order to avoid touching other register bits, since the first info (avg sample), came from DT. Signed-off-by: Rodrigo Gobbi Reviewed-by: David Lechner Link: https://patch.msgid.link/20250717221559.158872-1-rodrigo.gobbi.7@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ad22eebd717733a7c6de96e9e29e7a5f61ce8142 Author: Dmitry Baryshkov Date: Sat Aug 2 13:40:35 2025 +0300 drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts [ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ] Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached. In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events. Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change. Cc: Bjorn Andersson Cc: Konrad Dybcio Cc: linux-arm-msm@vger.kernel.org Acked-by: Laurent Pinchart Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 26f6a1dd5d81ad61a875a747698da6f27abf389b Author: Tetsuo Handa Date: Thu Jul 17 23:21:55 2025 +0900 media: imon: make send_packet() more robust [ Upstream commit eecd203ada43a4693ce6fdd3a58ae10c7819252c ] syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge hardware after early callbacks"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes until intf configured") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds. Link: https://syzkaller.appspot.com/bug?extid=592e2ab8775dbe0bf09a [1] Link: https://lkml.kernel.org/r/d6da6709-d799-4be3-a695-850bddd6eb24@rowland.harvard.edu [2] Signed-off-by: Tetsuo Handa Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0bf756ae1e69fec5e6332c37830488315d6d771b Author: Charalampos Mitrodimas Date: Tue Aug 12 15:51:25 2025 +0000 net: ipv6: fix field-spanning memcpy warning in AH output [ Upstream commit 2327a3d6f65ce2fe2634546dde4a25ef52296fec ] Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication. Reported-by: syzbot+01b0667934cdceb4451c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=01b0667934cdceb4451c Signed-off-by: Charalampos Mitrodimas Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 15def75e75a722b3e90452ca8085a90051ed87c8 Author: Ido Schimmel Date: Tue Aug 12 11:02:12 2025 +0300 bridge: Redirect to backup port when port is administratively down [ Upstream commit 3d05b24429e1de7a17c8fdccb04a04dbc8ad297b ] If a backup port is configured for a bridge port, the bridge will redirect known unicast traffic towards the backup port when the primary port is administratively up but without a carrier. This is useful, for example, in MLAG configurations where a system is connected to two switches and there is a peer link between both switches. The peer link serves as the backup port in case one of the switches loses its connection to the multi-homed system. In order to avoid flooding when the primary port loses its carrier, the bridge does not flush dynamic FDB entries pointing to the port upon STP disablement, if the port has a backup port. The above means that known unicast traffic destined to the primary port will be blackholed when the port is put administratively down, until the FDB entries pointing to it are aged-out. Given that the current behavior is quite weird and unlikely to be depended on by anyone, amend the bridge to redirect to the backup port also when the primary port is administratively down and not only when it does not have a carrier. The change is motivated by a report from a user who expected traffic to be redirected to the backup port when the primary port was put administratively down while debugging a network issue. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250812080213.325298-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a65cbffb0e81d39b9e6763aa4a94aa1c9d3488e3 Author: Niklas Schnelle Date: Thu Aug 7 15:55:40 2025 +0200 powerpc/eeh: Use result of error_detected() in uevent [ Upstream commit 704e5dd1c02371dfc7d22e1520102b197a3b628b ] Ever since uevent support was added for AER and EEH with commit 856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume"), it reported PCI_ERS_RESULT_NONE as uevent when recovery begins. Commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") subsequently amended AER to report the actual return value of error_detected(). Make the same change to EEH to align it with AER and s390. Suggested-by: Lukas Wunner Link: https://lore.kernel.org/linux-pci/aIp6LiKJor9KLVpv@wunner.de/ Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Kuppuswamy Sathyanarayanan Acked-by: Mahesh Salgaonkar Link: https://patch.msgid.link/20250807-add_err_uevents-v5-3-adf85b0620b0@linux.ibm.com Signed-off-by: Sasha Levin commit e269b500b23fc50ce9a002db59e6f0585e546f67 Author: Lukas Wunner Date: Tue Aug 12 15:42:29 2025 +0200 thunderbolt: Use is_pciehp instead of is_hotplug_bridge [ Upstream commit 5d03847175e81e86d4865456c15638faaf7c0634 ] The thunderbolt driver sets up device link dependencies from hotplug ports to the Host Router (aka Native Host Interface, NHI). When resuming from system sleep, this allows the Host Router to re-establish tunnels to attached Thunderbolt devices before the hotplug ports resume. To identify the hotplug ports, the driver utilizes the is_hotplug_bridge flag which also encompasses ACPI slots handled by the ACPI hotplug driver. Thunderbolt hotplug ports are always Hot-Plug Capable PCIe ports, so it is more apt to identify them with the is_pciehp flag. Similarly, hotplug ports on older Thunderbolt controllers have broken MSI support and are quirked to use legacy INTx interrupts instead. The quirk identifies them with is_hotplug_bridge, even though all affected ports are also matched by is_pciehp. So use is_pciehp here as well. Signed-off-by: Lukas Wunner Acked-by: Bjorn Helgaas Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 157b7b41a5d22d7d61d6998208fc5c7a31831c6f Author: Tiezhu Yang Date: Mon Aug 11 15:35:04 2025 +0800 net: stmmac: Check stmmac_hw_setup() in stmmac_resume() [ Upstream commit 6896c2449a1858acb643014894d01b3a1223d4e5 ] stmmac_hw_setup() may return 0 on success and an appropriate negative integer as defined in errno.h file on failure, just check it and then return early if failed in stmmac_resume(). Signed-off-by: Tiezhu Yang Reviewed-by: Maxime Chevallier Reviewed-by: Huacai Chen Link: https://patch.msgid.link/20250811073506.27513-2-yangtiezhu@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d178723da249eafcd32d4edf26f2cf72c24eebd4 Author: Kiryl Shutsemau Date: Tue Jun 24 17:59:18 2025 +0300 x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall [ Upstream commit 8ba38a7a9a699905b84fa97578a8291010dec273 ] emulate_vsyscall() expects to see X86_PF_INSTR in PFEC on a vsyscall page fault, but the CPU does not report X86_PF_INSTR if neither X86_FEATURE_NX nor X86_FEATURE_SMEP are enabled. X86_FEATURE_NX should be enabled on nearly all 64-bit CPUs, except for early P4 processors that did not support this feature. Instead of explicitly checking for X86_PF_INSTR, compare the fault address to RIP. On machines with X86_FEATURE_NX enabled, issue a warning if RIP is equal to fault address but X86_PF_INSTR is absent. [ dhansen: flesh out code comments ] Originally-by: Dave Hansen Reported-by: Andrew Cooper Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Andrew Cooper Link: https://lore.kernel.org/all/bd81a98b-f8d4-4304-ac55-d4151a1a77ab@intel.com Link: https://lore.kernel.org/all/20250624145918.2720487-1-kirill.shutemov%40linux.intel.com Signed-off-by: Sasha Levin commit 5ba991865ceeac24a8927289b14e0dfed2112699 Author: Jayesh Choudhary Date: Tue Jun 24 13:34:02 2025 +0530 drm/tidss: Set crtc modesetting parameters with adjusted mode [ Upstream commit cfb29225db20c56432a8525366321c0c09edfb2e ] TIDSS uses crtc_* fields to propagate its registers and set the clock rates. So set the CRTC modesetting timing parameters with the adjusted mode when needed, to set correct values. Cc: Tomi Valkeinen Signed-off-by: Jayesh Choudhary Link: https://lore.kernel.org/r/20250624080402.302526-1-j-choudhary@ti.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 603c103f9e305e2de06f9006edcb461c5f361d59 Author: Tomi Valkeinen Date: Wed Jul 23 13:05:09 2025 +0300 drm/tidss: Use the crtc_* timings when programming the HW [ Upstream commit 478306edc23eec4f0ec24a46222485910c66212d ] Use the crtc_* fields from drm_display_mode, instead of the "logical" fields. This shouldn't change anything in practice, but afaiu the crtc_* fields are the correct ones to use here. Reviewed-by: Aradhya Bhatia Tested-by: Parth Pancholi Tested-by: Jayesh Choudhary Reviewed-by: Devarsh Thakkar Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-3-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 965813f1afaf6ab66090acb8a4c40d966ecdac31 Author: Laurent Pinchart Date: Sun Aug 10 04:29:54 2025 +0300 media: pci: ivtv: Don't create fake v4l2_fh [ Upstream commit cc6e8d1ccea792d8550428e0831e3a35b0ccfddc ] The ivtv driver has a structure named ivtv_open_id that models an open file handle for the device. It embeds a v4l2_fh instance for file handles that correspond to a V4L2 video device, and stores a pointer to that v4l2_fh in struct ivtv_stream to identify which open file handle owns a particular stream. In addition to video devices, streams can be owned by ALSA PCM devices. Those devices do not make use of the v4l2_fh instance for obvious reasons, but the snd_ivtv_pcm_capture_open() function still initializes a "fake" v4l2_fh for the sole purpose of using it as an open file handle identifier. The v4l2_fh is not properly destroyed when the ALSA PCM device is closed, leading to possible resource leaks. Fortunately, the v4l2_fh instance pointed to by ivtv_stream is not accessed, only the pointer value is used for comparison. Replace it with a pointer to the ivtv_open_id structure that embeds the v4l2_fh, and don't initialize the v4l2_fh for ALSA PCM devices. Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 556da285679893a37c5935a5cccc13c316d6ce2a Author: Geoffrey McRae Date: Tue Jul 8 13:53:40 2025 +1000 drm/amdkfd: return -ENOTTY for unsupported IOCTLs [ Upstream commit 57af162bfc8c05332a28c4d458d246cc46d2746d ] Some kfd ioctls may not be available depending on the kernel version the user is running, as such we need to report -ENOTTY so userland can determine the cause of the ioctl failure. Signed-off-by: Geoffrey McRae Acked-by: Alex Deucher Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e04e3165bc8ba989d9db76e7875c49503626d957 Author: Wake Liu Date: Sat Aug 9 14:20:13 2025 +0800 selftests/net: Ensure assert() triggers in psock_tpacket.c [ Upstream commit bc4c0a48bdad7f225740b8e750fdc1da6d85e1eb ] The get_next_frame() function in psock_tpacket.c was missing a return statement in its default switch case, leading to a compiler warning. This was caused by a `bug_on(1)` call, which is defined as an `assert()`, being compiled out because NDEBUG is defined during the build. Instead of adding a `return NULL;` which would silently hide the error and could lead to crashes later, this change restores the original author's intent. By adding `#undef NDEBUG` before including , we ensure the assertion is active and will cause the test to abort if this unreachable code is ever executed. Signed-off-by: Wake Liu Link: https://patch.msgid.link/20250809062013.2407822-1-wakel@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 634d43ee1d23710ecadb22940a95129dbe0960a5 Author: Wake Liu Date: Thu Aug 7 16:09:32 2025 +0800 selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8 [ Upstream commit c36748e8733ef9c5f4cd1d7c4327994e5b88b8df ] The `__WORDSIZE` macro, defined in the non-standard `` header, is a GNU extension and not universally available with all toolchains, such as Clang when used with musl libc. This can lead to build failures in environments where this header is missing. The intention of the code is to determine the bit width of a C `long`. Replace the non-portable `__WORDSIZE` with the standard and portable `sizeof(long) * 8` expression to achieve the same result. This change also removes the inclusion of the now-unused `` header. Signed-off-by: Wake Liu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit be80a71699b485229e29f9ce24ed45deafa26e5a Author: Marcos Del Sol Vives Date: Sun Jul 6 01:32:08 2025 +0200 PCI: Disable MSI on RDC PCI to PCIe bridges [ Upstream commit ebc7086b39e5e4f3d3ca82caaea20538c9b62d42 ] RDC PCI to PCIe bridges, present on Vortex86DX3 and Vortex86EX2 SoCs, do not support MSIs. If enabled, interrupts generated by PCIe devices never reach the processor. I have contacted the manufacturer (DM&P) and they confirmed that PCI MSIs need to be disabled for them. Signed-off-by: Marcos Del Sol Vives Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250705233209.721507-1-marcos@orca.pet Signed-off-by: Sasha Levin commit 31caf9efba7e518b0a84409f74010a417f2e5b9a Author: Seyediman Seyedarab Date: Thu Jul 24 15:59:13 2025 -0400 drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf() [ Upstream commit 6510b62fe9303aaf48ff136ff69186bcfc32172d ] snprintf() returns the number of characters that *would* have been written, which can overestimate how much you actually wrote to the buffer in case of truncation. That leads to 'data += this' advancing the pointer past the end of the buffer and size going negative. Switching to scnprintf() prevents potential buffer overflows and ensures consistent behavior when building the output string. Signed-off-by: Seyediman Seyedarab Link: https://lore.kernel.org/r/20250724195913.60742-1-ImanDevel@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 19096bddf873c72a3636197d6f49021fbcd0a60c Author: Sathishkumar S Date: Tue Aug 5 21:28:25 2025 +0530 drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff [ Upstream commit 0e7581eda8c76d1ca4cf519631a4d4eb9f82b94c ] Acquire jpeg_pg_lock before changes to jpeg power state and release it after power off from idle work handler. Signed-off-by: Sathishkumar S Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b9d1d32766d3dc4090f7eafcffb350d60eb650cf Author: Lijo Lazar Date: Fri Jul 11 12:18:04 2025 +0530 drm/amd/pm: Use cached metrics data on arcturus [ Upstream commit 2f3b1ccf83be83a3330e38194ddfd1a91fec69be ] Cached metrics data validity is 1ms on arcturus. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 89af20042ea5d48fb7c347ab270b7401ef7ecda8 Author: Lijo Lazar Date: Fri Jul 11 12:15:45 2025 +0530 drm/amd/pm: Use cached metrics data on aldebaran [ Upstream commit e87577ef6daa0cfb10ca139c720f0c57bd894174 ] Cached metrics data validity is 1ms on aldebaran. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 446631df07140e8c2dd7cbe74ed4f8bc1b891d41 Author: Jens Kehne Date: Mon Aug 4 15:37:54 2025 +0200 mfd: da9063: Split chip variant reading in two bus transactions [ Upstream commit 9ac4890ac39352ccea132109e32911495574c3ec ] We observed the initial probe of the da9063 failing in da9063_get_device_type in about 30% of boots on a Xilinx ZynqMP based board. The problem originates in da9063_i2c_blockreg_read, which uses a single bus transaction to turn the register page and then read a register. On the bus, this should translate to a write to register 0, followed by a read to the target register, separated by a repeated start. However, we found that after the write to register 0, the controller sometimes continues directly with the register address of the read request, without sending the chip address or a repeated start in between, which makes the read request invalid. To fix this, separate turning the page and reading the register into two separate transactions. This brings the initialization code in line with the rest of the driver, which uses register maps (which to my knowledge do not use repeated starts after turning the page). This has been included in our kernel for several months and was recently included in a shipped product. For us, it reliably fixes the issue, and we have not observed any new issues. While the underlying problem is probably with the i2c controller or its driver, I still propose a change here in the interest of robustness: First, I'm not sure this issue can be fixed on the controller side, since there are other issues related to repeated start which can't (AR# 60695, AR# 61664). Second, similar problems might exist with other controllers. Signed-off-by: Jens Kehne Link: https://lore.kernel.org/r/20250804133754.3496718-1-jens.kehne@agilent.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit adde0c657c901d77fbb6aa4693a389c94149b3a8 Author: Arnd Bergmann Date: Thu Aug 7 09:19:28 2025 +0200 mfd: madera: Work around false-positive -Wininitialized warning [ Upstream commit 364752aa0c6ab0a06a2d5bfdb362c1ca407f1a30 ] clang-21 warns about one uninitialized variable getting dereferenced in madera_dev_init: drivers/mfd/madera-core.c:739:10: error: variable 'mfd_devs' is uninitialized when used here [-Werror,-Wuninitialized] 739 | mfd_devs, n_devs, | ^~~~~~~~ drivers/mfd/madera-core.c:459:33: note: initialize the variable 'mfd_devs' to silence this warning 459 | const struct mfd_cell *mfd_devs; | ^ | = NULL The code is actually correct here because n_devs is only nonzero when mfd_devs is a valid pointer, but this is impossible for the compiler to see reliably. Change the logic to check for the pointer as well, to make this easier for the compiler to follow. Signed-off-by: Arnd Bergmann Reviewed-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20250807071932.4085458-1-arnd@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d7bc1931a2565ebb70d68d4e65a057b4f588c075 Author: Alexander Stein Date: Fri Jul 25 09:11:50 2025 +0200 mfd: stmpe-i2c: Add missing MODULE_LICENSE [ Upstream commit 00ea54f058cd4cb082302fe598cfe148e0aadf94 ] This driver is licensed GPL-2.0-only, so add the corresponding module flag. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250725071153.338912-3-alexander.stein@ew.tq-group.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 72f7a31793bbffa06c4784d7cf357a0eb9a9138b Author: Alexander Stein Date: Fri Jul 25 09:07:48 2025 +0200 mfd: stmpe: Remove IRQ domain upon removal [ Upstream commit 57bf2a312ab2d0bc8ee0f4e8a447fa94a2fc877d ] The IRQ domain is (optionally) added during stmpe_probe, but never removed. Add the call to stmpe_remove. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250725070752.338376-1-alexander.stein@ew.tq-group.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit fa0d842eea8cb4a177314af8a746602fb7deb269 Author: Len Brown Date: Fri Sep 19 15:56:46 2025 -0400 tools/power x86_energy_perf_policy: Prefer driver HWP limits [ Upstream commit 2734fdbc9bb8a3aeb309ba0d62212d7f53f30bc7 ] When we are successful in using cpufreq min/max limits, skip setting the raw MSR limits entirely. This is necessary to avoid undoing any modification that the cpufreq driver makes to our sysfs request. eg. intel_pstate may take our request for a limit that is valid according to HWP.CAP.MIN/MAX and clip it to be within the range available in PLATFORM_INFO. Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 1c0eb3211e174eab258f2924ac6440ecf135cb49 Author: Len Brown Date: Fri Sep 19 14:07:02 2025 -0400 tools/power x86_energy_perf_policy: Enhance HWP enable [ Upstream commit c97c057d357c4b39b153e9e430bbf8976e05bd4e ] On enabling HWP, preserve the reserved bits in MSR_PM_ENABLE. Also, skip writing the MSR_PM_ENABLE if HWP is already enabled. Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 87de7b4213c1ce6621b9b70d1cb7a1139d5e5140 Author: Kaushlendra Kumar Date: Wed Aug 13 12:32:08 2025 +0530 tools/power x86_energy_perf_policy: Fix incorrect fopen mode usage [ Upstream commit 62127655b7ab7b8c2997041aca48a81bf5c6da0c ] The fopen_or_die() function was previously hardcoded to open files in read-only mode ("r"), ignoring the mode parameter passed to it. This patch corrects fopen_or_die() to use the provided mode argument, allowing for flexible file access as intended. Additionally, the call to fopen_or_die() in err_on_hypervisor() incorrectly used the mode "ro", which is not a valid fopen mode. This is fixed to use the correct "r" mode. Signed-off-by: Kaushlendra Kumar Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 2ba32bd019cf19a9806ebe4dae3b95fae8d9966d Author: Kaushlendra Kumar Date: Wed Sep 17 10:38:20 2025 +0530 tools/cpupower: Fix incorrect size in cpuidle_state_disable() [ Upstream commit 23199d2aa6dcaf6dd2da772f93d2c94317d71459 ] Fix incorrect size parameter passed to cpuidle_state_write_file() in cpuidle_state_disable(). The function was incorrectly using sizeof(disable) which returns the size of the unsigned int variable (4 bytes) instead of the actual length of the string stored in the 'value' buffer. Since 'value' is populated with snprintf() to contain the string representation of the disable value, we should use the length returned by snprintf() to get the correct string length for writing to the sysfs file. This ensures the correct number of bytes is written to the cpuidle state disable file in sysfs. Link: https://lore.kernel.org/r/20250917050820.1785377-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 481e609c7854adeea68c75d7fa04b3cd85a88e6b Author: Armin Wolf Date: Wed Sep 17 20:10:36 2025 +0200 hwmon: (dell-smm) Add support for Dell OptiPlex 7040 [ Upstream commit 53d3bd48ef6ff1567a75ca77728968f5ab493cb4 ] The Dell OptiPlex 7040 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/15 Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20250917181036.10972-5-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2617ae62f086132002fa1a8479c56d28dc44df2f Author: Jiri Olsa Date: Tue Sep 16 23:52:57 2025 +0200 uprobe: Do not emulate/sstep original instruction when ip is changed [ Upstream commit 4363264111e1297fa37aa39b0598faa19298ecca ] If uprobe handler changes instruction pointer we still execute single step) or emulate the original instruction and increment the (new) ip with its length. This makes the new instruction pointer bogus and application will likely crash on illegal instruction execution. If user decided to take execution elsewhere, it makes little sense to execute the original instruction, so let's skip it. Acked-by: Oleg Nesterov Acked-by: Andrii Nakryiko Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20250916215301.664963-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cf3e51d388e10bbc8170a67444cc4b113fcbc5ea Author: Daniel Lezcano Date: Mon Aug 4 17:23:19 2025 +0200 clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel [ Upstream commit 0b781f527d6f99e68e5b3780ae03cd69a7cb5c0c ] The driver uses the raw_readl() and raw_writel() functions. Those are not for MMIO devices. Replace them with readl() and writel() [ dlezcano: Fixed typo in the subject s/reald/readl/ ] Signed-off-by: Daniel Lezcano Acked-by: Arnd Bergmann Cc: Arnd Bergmann Link: https://lore.kernel.org/r/20250804152344.1109310-2-daniel.lezcano@linaro.org Signed-off-by: Sasha Levin commit 39805c73289162e018dc196c290eaf49ccd697f2 Author: Rafael J. Wysocki Date: Fri Sep 19 13:22:20 2025 +0200 cpuidle: Fail cpuidle device registration if there is one already [ Upstream commit 7b1b7961170e4fcad488755e5ffaaaf9bd527e8f ] Refuse to register a cpuidle device if the given CPU has a cpuidle device already and print a message regarding it. Without this, an attempt to register a new cpuidle device without unregistering the existing one leads to the removal of the existing cpuidle device without removing its sysfs interface. Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7f6993bd32243b684612507bd85b266b37a84916 Author: Kaushlendra Kumar Date: Thu Aug 28 12:00:00 2025 +0530 tools/cpupower: fix error return value in cpupower_write_sysfs() [ Upstream commit 57b100d4cf14276e0340eecb561005c07c129eb8 ] The cpupower_write_sysfs() function currently returns -1 on write failure, but the function signature indicates it should return an unsigned int. Returning -1 from an unsigned function results in a large positive value rather than indicating an error condition. Fix this by returning 0 on failure, which is more appropriate for an unsigned return type and maintains consistency with typical success/failure semantics where 0 indicates failure and non-zero indicates success (bytes written). Link: https://lore.kernel.org/r/20250828063000.803229-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6e9e9558da651d562c21a192ecc7ce0bb0217786 Author: Svyatoslav Ryhel Date: Tue Sep 9 10:43:04 2025 +0300 video: backlight: lp855x_bl: Set correct EPROM start for LP8556 [ Upstream commit 07c7efda24453e05951fb2879f5452b720b91169 ] According to LP8556 datasheet EPROM region starts at 0x98 so adjust value in the driver accordingly. Signed-off-by: Svyatoslav Ryhel Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250909074304.92135-2-clamor95@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e8cde03de8674b05f2c5e0870729049eba517800 Author: Daniel Wagner Date: Tue Sep 2 12:22:03 2025 +0200 nvme-fc: use lock accessing port_state and rport state [ Upstream commit 891cdbb162ccdb079cd5228ae43bdeebce8597ad ] nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport. Reported-by: Shinichiro Kawasaki Closes: https://lore.kernel.org/all/u4ttvhnn7lark5w3sgrbuy2rxupcvosp4qmvj46nwzgeo5ausc@uyrkdls2muwx Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 2f4852db87e25d4e226b25cb6f652fef9504360e Author: Daniel Wagner Date: Tue Sep 2 12:22:01 2025 +0200 nvmet-fc: avoid scheduling association deletion twice [ Upstream commit f2537be4f8421f6495edfa0bc284d722f253841d ] When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted. Reported-by: Shinichiro Kawasaki Closes: https://lore.kernel.org/all/rsdinhafrtlguauhesmrrzkybpnvwantwmyfq2ih5aregghax5@mhr7v3eryci3/ Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 75a98126757ea080ef7241d93e82b12ddaadc0f4 Author: Amirreza Zarrabi Date: Thu Sep 11 21:07:42 2025 -0700 tee: allow a driver to allocate a tee_device without a pool [ Upstream commit 6dbcd5a9ab6cb6644e7d728521da1c9035ec7235 ] A TEE driver doesn't always need to provide a pool if it doesn't support memory sharing ioctls and can allocate memory for TEE messages in another way. Although this is mentioned in the documentation for tee_device_alloc(), it is not handled correctly. Reviewed-by: Sumit Garg Signed-off-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 5a7e2d5d1b68800a41017da3326505b2166b2943 Author: Hans de Goede Date: Fri Sep 12 22:00:17 2025 +0200 ACPICA: dispatcher: Use acpi_ds_clear_operands() in acpi_ds_call_control_method() [ Upstream commit e9dff11a7a50fcef23fe3e8314fafae6d5641826 ] When deleting the previous walkstate operand stack acpi_ds_call_control_method() was deleting obj_desc->Method.param_count operands. But Method.param_count does not necessarily match this_walk_state->num_operands, it may be either less or more. After correcting the for loop to check `i < this_walk_state->num_operands` the code is identical to acpi_ds_clear_operands(), so just outright replace the code with acpi_ds_clear_operands() to fix this. Link: https://github.com/acpica/acpica/commit/53fc0220 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 13257496a496d7a320abb66aa7832422e816cfdd Author: Sarthak Garg Date: Mon Sep 8 16:11:19 2025 +0530 mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card [ Upstream commit 08b68ca543ee9d5a8d2dc406165e4887dd8f170b ] For Qualcomm SoCs which needs level shifter for SD card, extra delay is seen on receiver data path. To compensate this delay enable tuning for SDR50 mode for targets which has level shifter. SDHCI_SDR50_NEEDS_TUNING caps will be set for targets with level shifter on Qualcomm SOC's. Signed-off-by: Sarthak Garg Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e3f7173df91b6cce12162c7ac91df761282c4653 Author: Fabien Proriol Date: Mon Jul 7 17:55:08 2025 +0200 power: supply: sbs-charger: Support multiple devices [ Upstream commit 3ec600210849cf122606e24caab85f0b936cf63c ] If we have 2 instances of sbs-charger in the DTS, the driver probe for the second instance will fail: [ 8.012874] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered [ 8.039094] sbs-charger 18-0009: ltc4100: smart charger device registered [ 8.112911] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered [ 8.134533] sysfs: cannot create duplicate filename '/class/power_supply/sbs-charger' [ 8.143871] CPU: 3 PID: 295 Comm: systemd-udevd Tainted: G O 5.10.147 #22 [ 8.151974] Hardware name: ALE AMB (DT) [ 8.155828] Call trace: [ 8.158292] dump_backtrace+0x0/0x1d4 [ 8.161960] show_stack+0x18/0x6c [ 8.165280] dump_stack+0xcc/0x128 [ 8.168687] sysfs_warn_dup+0x60/0x7c [ 8.172353] sysfs_do_create_link_sd+0xf0/0x100 [ 8.176886] sysfs_create_link+0x20/0x40 [ 8.180816] device_add+0x270/0x7a4 [ 8.184311] __power_supply_register+0x304/0x560 [ 8.188930] devm_power_supply_register+0x54/0xa0 [ 8.193644] sbs_probe+0xc0/0x214 [sbs_charger] [ 8.198183] i2c_device_probe+0x2dc/0x2f4 [ 8.202196] really_probe+0xf0/0x510 [ 8.205774] driver_probe_device+0xfc/0x160 [ 8.209960] device_driver_attach+0xc0/0xcc [ 8.214146] __driver_attach+0xc0/0x170 [ 8.218002] bus_for_each_dev+0x74/0xd4 [ 8.221862] driver_attach+0x24/0x30 [ 8.225444] bus_add_driver+0x148/0x250 [ 8.229283] driver_register+0x78/0x130 [ 8.233140] i2c_register_driver+0x4c/0xe0 [ 8.237250] sbs_driver_init+0x20/0x1000 [sbs_charger] [ 8.242424] do_one_initcall+0x50/0x1b0 [ 8.242434] do_init_module+0x44/0x230 [ 8.242438] load_module+0x2200/0x27c0 [ 8.242442] __do_sys_finit_module+0xa8/0x11c [ 8.242447] __arm64_sys_finit_module+0x20/0x30 [ 8.242457] el0_svc_common.constprop.0+0x64/0x154 [ 8.242464] do_el0_svc+0x24/0x8c [ 8.242474] el0_svc+0x10/0x20 [ 8.242481] el0_sync_handler+0x108/0x114 [ 8.242485] el0_sync+0x180/0x1c0 [ 8.243847] sbs-charger 20-0009: Failed to register power supply [ 8.287934] sbs-charger: probe of 20-0009 failed with error -17 This is mainly because the "name" field of power_supply_desc is a constant. This patch fixes the issue by reusing the same approach as sbs-battery. With this patch, the result is: [ 7.819532] sbs-charger 18-0009: ltc4100: smart charger device registered [ 7.825305] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered [ 7.887423] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered [ 7.893501] sbs-charger 20-0009: ltc4100: smart charger device registered Signed-off-by: Fabien Proriol Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a59c9c1370dbf865d123e43ddf45f80ad98cca81 Author: Chuande Chen Date: Thu Aug 14 13:39:40 2025 +0800 hwmon: (sbtsi_temp) AMD CPU extended temperature range support [ Upstream commit d9d61f1da35038793156c04bb13f0a1350709121 ] Many AMD CPUs can support this feature now. We would get a wrong CPU DIE temperature if don't consider this. In low-temperature environments, the CPU die temperature can drop below zero. So many platforms would like to make extended temperature range as their default configuration. Default temperature range (0C to 255.875C). Extended temperature range (-49C to +206.875C). Ref Doc: AMD V3000 PPR (Doc ID #56558). Signed-off-by: Chuande Chen Link: https://lore.kernel.org/r/20250814053940.96764-1-chenchuande@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9545f5ef825862344bc9132082a1696f689a9cb8 Author: Hans de Goede Date: Fri Aug 29 16:27:48 2025 +0200 ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[] [ Upstream commit 4405a214df146775338a1e6232701a29024b82e1 ] Some x86/ACPI laptops with MIPI cameras have a INTC10DE or INTC10E0 ACPI device in the _DEP dependency list of the ACPI devices for the camera- sensors (which have flags.honor_deps set). These devices are for an Intel Vision CVS chip for which an out of tree driver is available [1]. The camera sensor works fine without a driver being loaded for this ACPI device on the 2 laptops this was tested on: ThinkPad X1 Carbon Gen 12 (Meteor Lake) ThinkPad X1 2-in-1 Gen 10 (Arrow Lake) For now add these HIDs to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met and an i2c_client for the camera sensor will get instantiated. Link: https://github.com/intel/vision-drivers/ [1] Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250829142748.21089-1-hansg@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 799f75a894a67cef2d011507887fbbc86c201c5b Author: Shang song (Lenovo) Date: Mon Aug 25 23:02:29 2025 -0400 ACPI: PRM: Skip handlers with NULL handler_address or NULL VA [ Upstream commit 311942ce763e21dacef7e53996d5a1e19b8adab1 ] If handler_address or mapped VA is NULL, the related buffer address and VA can be ignored, so make acpi_parse_prmt() skip the current handler in those cases. Signed-off-by: Shang song (Lenovo) Link: https://patch.msgid.link/20250826030229.834901-1-shangsong2@foxmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 2ca16b41e88bc1aace66a1abc397db6300400c18 Author: Christian Bruel Date: Tue Sep 2 11:10:45 2025 +0200 irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment [ Upstream commit 2ef3886ce626dcdab0cbc452dbbebc19f57133d8 ] The PCI Local Bus Specification 3.0 (section 6.8.1.6) allows modifying the low-order bits of the MSI Message DATA register to encode nr_irqs interrupt numbers in the log2(nr_irqs) bits for the domain. The problem arises if the base vector (GICV2m base spi) is not aligned with nr_irqs; in this case, the low-order log2(nr_irqs) bits from the base vector conflict with the nr_irqs masking, causing the wrong MSI interrupt to be identified. To fix this, use bitmap_find_next_zero_area_off() instead of bitmap_find_free_region() to align the initial base vector with nr_irqs. Signed-off-by: Christian Bruel Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/all/20250902091045.220847-1-christian.bruel@foss.st.com Signed-off-by: Sasha Levin commit 1ba13dde6a45b51d73ec11330d86e56ec2ae1c85 Author: Kees Cook Date: Sat Aug 30 19:23:53 2025 -0700 arc: Fix __fls() const-foldability via __builtin_clzl() [ Upstream commit a3fecb9160482367365cc384c59dd220b162b066 ] While tracking down a problem where constant expressions used by BUILD_BUG_ON() suddenly stopped working[1], we found that an added static initializer was convincing the compiler that it couldn't track the state of the prior statically initialized value. Tracing this down found that ffs() was used in the initializer macro, but since it wasn't marked with __attribute__const__, the compiler had to assume the function might change variable states as a side-effect (which is not true for ffs(), which provides deterministic math results). For arc architecture with CONFIG_ISA_ARCV2=y, the __fls() function uses __builtin_arc_fls() which lacks GCC's const attribute, preventing compile-time constant folding, and KUnit testing of ffs/fls fails on arc[3]. A patch[2] to GCC to solve this has been sent. Add a fix for this by handling compile-time constants with the standard __builtin_clzl() builtin (which has const attribute) while preserving the optimized arc-specific builtin for runtime cases. This has the added benefit of skipping runtime calculation of compile-time constant values. Even with the GCC bug fixed (which is about "attribute const") this is a good change to avoid needless runtime costs, and should be done regardless of the state of GCC's bug. Build tested ARCH=arc allyesconfig with GCC arc-linux 15.2.0. Link: https://github.com/KSPP/linux/issues/364 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508031025.doWxtzzc-lkp@intel.com/ [3] Signed-off-by: Kees Cook Acked-by: Vineet Gupta Signed-off-by: Yury Norov (NVIDIA) Signed-off-by: Sasha Levin commit 55cf586b9556863e3c2a45460aba71bcb2be5bcd Author: Dennis Beier Date: Sat Aug 30 16:43:59 2025 +0200 cpufreq/longhaul: handle NULL policy in longhaul_exit [ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ] longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962 Signed-off-by: Dennis Beier Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 916f62bf6964777ad20ed731832b404a2b06f1a7 Author: Ricardo B. Marlière Date: Thu Aug 28 10:12:33 2025 -0300 selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2 [ Upstream commit 98857d111c53954aa038fcbc4cf48873e4240f7c ] Commit e9fc3ce99b34 ("libbpf: Streamline error reporting for high-level APIs") redefined the way that bpf_prog_detach2() returns. Therefore, adapt the usage in test_lirc_mode2_user.c. Signed-off-by: Ricardo B. Marlière Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250828-selftests-bpf-v1-1-c7811cd8b98c@suse.com Signed-off-by: Sasha Levin commit 76ab1edadf695f152246ba2440929908ca27368a Author: Mario Limonciello (AMD) Date: Wed Aug 20 12:09:26 2025 -0500 ACPI: video: force native for Lenovo 82K8 [ Upstream commit f144bc21befdcf8e54d2f19b23b4e84f13be01f9 ] Lenovo 82K8 has a broken brightness control provided by nvidia_wmi_ec. Add a quirk to prevent using it. Reported-by: Wilson Alvarez Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4512 Tested-by: Wilson Alvarez Signed-off-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20250820170927.895573-1-superm1@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit edc0b38f26fc65e8b1f3c569fe0fd8c0613f3ef7 Author: Jiayi Li Date: Mon Aug 4 10:48:25 2025 +0800 memstick: Add timeout to prevent indefinite waiting [ Upstream commit b65e630a55a490a0269ab1e4a282af975848064c ] Add timeout handling to wait_for_completion calls in memstick_set_rw_addr() and memstick_alloc_card() to prevent indefinite blocking in case of hardware or communication failures. Signed-off-by: Jiayi Li Link: https://lore.kernel.org/r/20250804024825.1565078-1-lijiayi@kylinos.cn Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9e18372fcf173f947b44a0a3a73d741008e9f728 Author: Biju Das Date: Sun Jun 29 21:38:56 2025 +0100 mmc: host: renesas_sdhi: Fix the actual clock [ Upstream commit 9c174e4dacee9fb2014a4ffc953d79a5707b77e4 ] Wrong actual clock reported, if the SD clock division ratio is other than 1:1(bits DIV[7:0] in SD_CLK_CTRL are set to 11111111). On high speed mode, cat /sys/kernel/debug/mmc1/ios Without the patch: clock: 50000000 Hz actual clock: 200000000 Hz After the fix: clock: 50000000 Hz actual clock: 50000000 Hz Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20250629203859.170850-1-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit fd031d98081eb19808bdad45b51c0944595b1900 Author: Chi Zhang Date: Thu Aug 7 14:20:38 2025 +0800 pinctrl: single: fix bias pull up/down handling in pin_config_set [ Upstream commit 236152dd9b1675a35eee912e79e6c57ca6b6732f ] In the pin_config_set function, when handling PIN_CONFIG_BIAS_PULL_DOWN or PIN_CONFIG_BIAS_PULL_UP, the function calls pcs_pinconf_clear_bias() which writes the register. However, the subsequent operations continue using the stale 'data' value from before the register write, effectively causing the bias clear operation to be overwritten and not take effect. Fix this by reading the 'data' value from the register after calling pcs_pinconf_clear_bias(). This bug seems to have existed when this code was first merged in commit 9dddb4df90d1 ("pinctrl: single: support generic pinconf"). Signed-off-by: Chi Zhang Link: https://lore.kernel.org/20250807062038.13610-1-chizhang@asrmicro.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 13ce905f0777d07780e2f34401715a0e4241a42b Author: Thomas Weißschuh Date: Mon Aug 11 14:08:04 2025 +0200 bpf: Don't use %pK through printk [ Upstream commit 2caa6b88e0ba0231fb4ff0ba8e73cedd5fb81fc8 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250811-restricted-pointers-bpf-v1-1-a1d7cc3cb9e7@linutronix.de Signed-off-by: Sasha Levin commit 49be75e00d21f3da60016e612827ba9416cad6ca Author: Thomas Weißschuh Date: Mon Aug 11 09:48:30 2025 +0200 soc: ti: pruss: don't use %pK through printk [ Upstream commit a5039648f86424885aae37f03dc39bc9cb972ecb ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250811-restricted-pointers-soc-v2-1-7af7ed993546@linutronix.de Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit ed7b7fbf2d5f5b35e7632f97ea97afcdc5a02221 Author: Thomas Weißschuh Date: Mon Aug 11 14:10:21 2025 +0200 spi: loopback-test: Don't use %pK through printk [ Upstream commit b832b19318534bb4f1673b24d78037fee339c679 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20250811-restricted-pointers-spi-v1-1-32c47f954e4d@linutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d06bbd6f5cd8fcdf2361cd010f73a8d09e6643ce Author: Jens Reidel Date: Sun Jul 27 01:56:46 2025 +0200 soc: qcom: smem: Fix endian-unaware access of num_entries [ Upstream commit 19e7aa0e9e46d0ad111a4af55b3d681b6ad945e0 ] Add a missing le32_to_cpu when accessing num_entries, which is always a little endian integer. Fixes booting on Xiaomi Mi 9T (xiaomi-davinci) in big endian. Signed-off-by: Jens Reidel Link: https://lore.kernel.org/r/20250726235646.254730-1-adrian@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9a0d4017a138f62f97e5b3b463fbd0c7e0ae02fc Author: Ryan Chen Date: Thu Aug 7 08:52:08 2025 +0800 soc: aspeed: socinfo: Add AST27xx silicon IDs [ Upstream commit c30dcfd4b5a0f0e3fe7138bf287f6de6b1b00278 ] Extend the ASPEED SoC info driver to support AST27XX silicon IDs. Signed-off-by: Ryan Chen Link: https://patch.msgid.link/20250807005208.3517283-1-ryan_chen@aspeedtech.com Signed-off-by: Andrew Jeffery Signed-off-by: Sasha Levin commit 04dde9a7cb7361fdb31e075835c8a2de8c3832f6 Author: Damien Le Moal Date: Mon Nov 3 07:46:31 2025 -0500 block: make REQ_OP_ZONE_OPEN a write operation [ Upstream commit 19de03b312d69a7e9bacb51c806c6e3f4207376c ] A REQ_OP_OPEN_ZONE request changes the condition of a sequential zone of a zoned block device to the explicitly open condition (BLK_ZONE_COND_EXP_OPEN). As such, it should be considered a write operation. Change this operation code to be an odd number to reflect this. The following operation numbers are changed to keep the numbering compact. No problems were reported without this change as this operation has no data. However, this unifies the zone operation to reflect that they modify the device state and also allows strengthening checks in the block layer, e.g. checking if this operation is not issued against a read-only device. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe [ relocated REQ_OP_ZONE_APPEND from 15 to 21 to resolve numbering conflict ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6abeff03cb79a2c7f4554a8e8738acd35bb37152 Author: Thomas Zimmermann Date: Mon Nov 3 10:06:26 2025 -0500 drm/sysfb: Do not dereference NULL pointer in plane reset [ Upstream commit 14e02ed3876f4ab0ed6d3f41972175f8b8df3d70 ] The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier) Signed-off-by: Thomas Zimmermann Fixes: b71565022031 ("drm/gem: Export implementation of shadow-plane helpers") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dri-devel/aPIDAsHIUHp_qSW4@stanley.mountain/ Cc: Thomas Zimmermann Cc: Melissa Wen Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.15+ Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20251017091407.58488-1-tzimmermann@suse.de [ removed drm_format_conv_state_init() call ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit afd6e9fe377f44817da9bbcf259c921f314a3f74 Author: Philipp Stanner Date: Mon Nov 3 10:44:46 2025 -0500 drm/sched: Fix race in drm_sched_entity_select_rq() [ Upstream commit d25e3a610bae03bffc5c14b5d944a5d0cd844678 ] In a past bug fix it was forgotten that entity access must be protected by the entity lock. That's a data race and potentially UB. Move the spin_unlock() to the appropriate position. Cc: stable@vger.kernel.org # v5.13+ Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3") Reviewed-by: Tvrtko Ursulin Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251022063402.87318-2-phasta@kernel.org [ adapted lock field name from entity->lock to entity->rq_lock ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9ec40fba7357df2d36f4c2e2f3b9b1a4fba0a272 Author: Owen Gu Date: Mon Sep 15 17:29:07 2025 +0800 usb: gadget: f_fs: Fix epfile null pointer access after ep enable. commit cfd6f1a7b42f62523c96d9703ef32b0dbc495ba4 upstream. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues Signed-off-by: Owen Gu Link: https://lore.kernel.org/r/20250915092907.17802-1-guhuinan@xiaomi.com Signed-off-by: Greg Kroah-Hartman commit e6f1413b1cfbcb4f7ae50393ccd12a311e1eccf1 Author: Matthieu Baerts (NGI0) Date: Fri Oct 17 18:24:02 2025 +0200 Revert "docs/process/howto: Replace C89 with C11" This reverts commit dc52117cd797f71f9686fa0cec91509eb7a9623d which is commit 2f3f53d62307262f0086804ea7cea99b0e085450 upstream. In this kernel version, C89 is still the default ISO standard. The reverted commit was fixing commit e8c07082a810 ("Kbuild: move to -std=gnu11"), introduced in v5.18, and not backported to older versions. It was then not supported to be backported to v5.15. It can then safely be reverted. Fixes: 2f3f53d62307 ("docs/process/howto: Replace C89 with C11") Signed-off-by: Matthieu Baerts (NGI0) Cc: Akira Yokosawa Cc: Arnd Bergmann Cc: Federico Vaga Cc: Alex Shi Cc: Hu Haowen Cc: Tsugikazu Shibata Cc: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit 518eadd15f7ecde6d301974388c6be03d5c57a0c Author: Matthieu Baerts (NGI0) Date: Fri Oct 17 18:24:01 2025 +0200 arch: back to -std=gnu89 in < v5.18 Recent fixes have been backported to < v5.18 to fix build issues with GCC 5.15. They all force -std=gnu11 in the CFLAGS, "because [the kernel] requests the gnu11 standard via '-std=' in the main Makefile". This is true for >= 5.18 versions, but not before. This switch to -std=gnu11 has been done in commit e8c07082a810 ("Kbuild: move to -std=gnu11"). For a question of uniformity, force -std=gnu89, similar to what is done in the main Makefile. Note: the fixes tags below refers to upstream commits, but this fix is only for kernels not having commit e8c07082a810 ("Kbuild: move to -std=gnu11"). Fixes: 7cbb015e2d3d ("parisc: fix building with gcc-15") Fixes: 3b8b80e99376 ("s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS") Fixes: b3bee1e7c3f2 ("x86/boot: Compile boot code with -std=gnu11 too") Fixes: ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15") Fixes: 8ba14d9f490a ("efi: libstub: Use '-std=gnu11' to fix build with GCC 15") Signed-off-by: Matthieu Baerts (NGI0) Cc: Nathan Chancellor Cc: Ard Biesheuvel Cc: Alexey Dobriyan Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit f28b14d235a810e4f6634832062b6e0ffc482b5a Author: Alexey Dobriyan Date: Fri Oct 17 18:24:00 2025 +0200 x86/boot: Compile boot code with -std=gnu11 too commit b3bee1e7c3f2b1b77182302c7b2131c804175870 upstream. Use -std=gnu11 for consistency with main kernel code. It doesn't seem to change anything in vmlinux. Signed-off-by: Alexey Dobriyan Signed-off-by: Ingo Molnar Acked-by: H. Peter Anvin (Intel) Link: https://lore.kernel.org/r/2058761e-12a4-4b2f-9690-3c3c1c9902a5@p183 [ This kernel version doesn't build with GCC 15: In file included from include/uapi/linux/posix_types.h:5, from include/uapi/linux/types.h:14, from include/linux/types.h:6, from arch/x86/realmode/rm/wakeup.h:11, from arch/x86/realmode/rm/wakemain.c:2: 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:30:33: error: 'bool' cannot be defined via 'typedef' 30 | typedef _Bool bool; | ^~~~ include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards include/linux/types.h:30:1: warning: useless type name in empty declaration 30 | typedef _Bool bool; | ^~~~~~~ The fix is similar to commit ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15") which has been backported to this kernel. Note: In < 5.18 version, -std=gnu89 is used instead of -std=gnu11, see commit e8c07082a810 ("Kbuild: move to -std=gnu11"). I suggest not to modify that in this commit here as all the other similar fixes to support GCC 15 set -std=gnu11. This can be done in a dedicated commit if needed. ] Signed-off-by: Matthieu Baerts (NGI0) Cc: Nathan Chancellor Cc: Dave Hansen Cc: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 8050bbc2a2b9b25f19ab620db169ff78e7bb26ab Author: Mathias Nyman Date: Mon Oct 27 14:42:52 2025 -0400 xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event [ Upstream commit f3d12ec847b945d5d65846c85f062d07d5e73164 ] DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fe9092c42877f5f8e0864ee6456be8b993edf72d Author: Mathias Nyman Date: Mon Oct 27 14:42:51 2025 -0400 xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive. [ Upstream commit cab63934c33b12c0d1e9f4da7450928057f2c142 ] Event polling delay is set to 0 if there are any pending requests in either rx or tx requests lists. Checking for pending requests does not work well for "IN" transfers as the tty driver always queues requests to the list and TRBs to the ring, preparing to receive data from the host. This causes unnecessary busylooping and cpu hogging. Only set the event polling delay to 0 if there are pending tx "write" transfers, or if it was less than 10ms since last active data transfer in any direction. Cc: Łukasz Bartosik Fixes: fb18e5bb9660 ("xhci: dbc: poll at different rate depending on data transfer activity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250505125630.561699-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 79d7094ecd755d123ba7c3ae207ddadf5438753e Author: Mathias Nyman Date: Mon Oct 27 14:42:50 2025 -0400 xhci: dbc: Improve performance by removing delay in transfer event polling. [ Upstream commit 03e3d9c2bd85cda941b3cf78e895c1498ac05c5f ] Queue event polling work with 0 delay in case there are pending transfers queued up. This is part 2 of a 3 part series that roughly triples dbc performace when using adb push and pull over dbc. Max/min push rate after patches is 210/118 MB/s, pull rate 171/133 MB/s, tested with large files (300MB-9GB) by Łukasz Bartosik First performance improvement patch was commit 31128e7492dc ("xhci: dbc: add dbgtty request to end of list once it completes") Cc: Łukasz Bartosik Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241227120142.1035206-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2f5c3743466f7eaf52ee9297c513062333213ffb Author: Uday M Bhat Date: Mon Oct 27 14:42:49 2025 -0400 xhci: dbc: Allow users to modify DbC poll interval via sysfs [ Upstream commit de3edd47a18fe05a560847cc3165871474e08196 ] xhci DbC driver polls the host controller for DbC events at a reduced rate when DbC is enabled but there are no active data transfers. Allow users to modify this reduced poll interval via dbc_poll_interval_ms sysfs entry. Unit is milliseconds and accepted range is 0 to 5000. Max interval of 5000 ms is selected as it matches the common 5 second timeout used in usb stack. Default value is 64 milliseconds. A long interval is useful when users know there won't be any activity on systems connected via DbC for long periods, and want to avoid battery drainage due to unnecessary CPU usage. Example being Android Debugger (ADB) usage over DbC on ChromeOS systems running Android Runtime. [minor changes and rewording -Mathias] Co-developed-by: Samuel Jacob Signed-off-by: Samuel Jacob Signed-off-by: Uday M Bhat Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240626124835.1023046-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d596d39e16e38c25cbe2cb9c6ef54cf69cd394e2 Author: Mathias Nyman Date: Mon Oct 27 14:42:48 2025 -0400 xhci: dbc: poll at different rate depending on data transfer activity [ Upstream commit fb18e5bb96603cc79d97f03e4c05f3992cf28624 ] DbC driver starts polling for events immediately when DbC is enabled. The current polling interval is 1ms, which keeps the CPU busy, impacting power management even when there are no active data transfers. Solve this by polling at a slower rate, with a 64ms interval as default until a transfer request is queued, or if there are still are pending unhandled transfers at event completion. Tested-by: Uday M Bhat Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240229141438.619372-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 902f900b46e9f6d2d948862bccd2368c7a044c18 Author: Mathias Nyman Date: Mon Oct 27 14:42:47 2025 -0400 xhci: dbc: Provide sysfs option to configure dbc descriptors [ Upstream commit edf1664f3249a091a2b91182fc087b3253b0b4c2 ] When DbC is enabled the first port on the xHC host acts as a usb device. xHC provides the descriptors automatically when the DbC device is enumerated. Most of the values are hardcoded, but some fields such as idProduct, idVendor, bcdDevice and bInterfaceProtocol can be modified. Add sysfs entries that allow userspace to change these. User can only change them before dbc is enabled, i.e. before writing "enable" to dbc sysfs file as we don't want these values to change while device is connected, or during enumeration. Add documentation for these entries in Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20230317154715.535523-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 42ccfa662c2eea20cd53abb7e0d532ff7e0818a8 Author: Babu Moger Date: Tue Oct 28 10:56:50 2025 -0500 x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID [ Upstream commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 ] Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state. When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked. resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked. This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter). Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again. Example scenario that results in mistaken overflow ================================================== 1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group. $mount -t resctrl resctrl /sys/fs/resctrl $mkdir /sys/fs/resctrl/mon_groups/test1/ $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 21323 <- Total bytes on domain 0 "Unavailable" <- Total bytes on domain 1 Task is running on domain 0. Counter on domain 1 is "Unavailable". 2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 7345357 <- Total bytes on domain 0 4545 <- Total bytes on domain 1 3. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes "Unavailable" <- Total bytes on domain 0 434341 <- Total bytes on domain 1 4. Since the task continues to migrate between domains, it may eventually return to domain 0. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 17592178699059 <- Overflow on domain 0 3232332 <- Total bytes on domain 1 In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0. Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta. In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state. Here is the text from APM [1] available from [2]. "In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first QM_CTR read when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, a QM_CTR read with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read." [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM). [ bp: Split commit message into smaller paragraph chunks for better consumption. ] Fixes: 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Tested-by: Reinette Chatre Cc: stable@vger.kernel.org # needs adjustments for <= v6.17 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2] (cherry picked from commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92) [babu.moger@amd.com: Fix conflict in monitor.c for v5.15 stable] Signed-off-by: Greg Kroah-Hartman commit 12a895faa0c93ebc679a135be317029371ea413e Author: Emanuele Ghidoli Date: Sun Nov 2 15:30:39 2025 -0500 net: phy: dp83867: Disable EEE support as not implemented [ Upstream commit 84a905290cb4c3d9a71a9e3b2f2e02e031e7512f ] While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures. The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY. Call phy_disable_eee during phy initialization to prevent EEE from being enabled on DP83867 PHYs. Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1445244/dp83867ir-dp83867-disable-eee-lpi Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/658638/dp83867ir-eee-energy-efficient-ethernet Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251023144857.529566-1-ghidoliemanuele@gmail.com Signed-off-by: Jakub Kicinski [ replaced phy_disable_eee() call with direct eee_broken_modes assignment ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56612e80a80b314d966bf83c03705b5aa8e0b319 Author: Celeste Liu Date: Mon Oct 27 20:47:27 2025 +0800 can: gs_usb: increase max interface to U8_MAX commit 2a27f6a8fb5722223d526843040f747e9b0e8060 upstream This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu Cc: stable@vger.kernel.org Reviewed-by: Vincent Mailhol Signed-off-by: Celeste Liu Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacanthus.name Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 941285def6f608be046e647d8f46281a5d124b1b Author: Lad Prabhakar Date: Mon Oct 27 09:49:31 2025 -0400 net: ravb: Enforce descriptor type ordering [ Upstream commit 5370c31e84b0e0999c7b5ff949f4e104def35584 ] Ensure the TX descriptor type fields are published in a safe order so the DMA engine never begins processing a descriptor chain before all descriptor fields are fully initialised. For multi-descriptor transmits the driver writes DT_FEND into the last descriptor and DT_FSTART into the first. The DMA engine begins processing when it observes DT_FSTART. Move the dma_wmb() barrier so it executes immediately after DT_FEND and immediately before writing DT_FSTART (and before DT_FSINGLE in the single-descriptor case). This guarantees that all prior CPU writes to the descriptor memory are visible to the device before DT_FSTART is seen. This avoids a situation where compiler/CPU reordering could publish DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to start on a partially initialised chain and causing corrupted transmissions or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as transmit queue timeouts and device resets. Fixes: 2f45d1902acf ("ravb: minimize TX data copying") Cc: stable@vger.kernel.org Co-developed-by: Fabrizio Castro Signed-off-by: Fabrizio Castro Signed-off-by: Lad Prabhakar Reviewed-by: Niklas Söderlund Link: https://patch.msgid.link/20251017151830.171062-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6664de2a13b5e7013c02643b8ed1cf805cc5b98e Author: Biju Das Date: Mon Oct 27 09:49:30 2025 -0400 ravb: Exclude gPTP feature support for RZ/G2L [ Upstream commit 7e09a052dc4e30ce07fd7b3aa58a7d993f73a9d7 ] R-Car supports gPTP feature whereas RZ/G2L does not support it. This patch excludes gtp feature support for RZ/G2L. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Signed-off-by: David S. Miller Stable-dep-of: 5370c31e84b0 ("net: ravb: Enforce descriptor type ordering") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 381eb91874a69fb58bb608309c70fdc6a01b6cfb Author: Xu Yang Date: Mon Oct 27 12:28:58 2025 -0400 dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp [ Upstream commit 268eb6fb908bc82ce479e4dba9a2cad11f536c9c ] Only i.MX8MP need dma-range property to let USB controller work properly. Remove dma-range from required list and add limitation for imx8mp. Fixes: d2a704e29711 ("dt-bindings: usb: dwc3-imx8mp: add imx8mp dwc3 glue bindings") Cc: stable Reviewed-by: Jun Li Signed-off-by: Xu Yang Reviewed-by: Frank Li Acked-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bfb5e825c206ca119e6fe0fe91c460574102be19 Author: Artem Shimko Date: Mon Oct 27 13:31:45 2025 -0400 serial: 8250_dw: handle reset control deassert error [ Upstream commit daeb4037adf7d3349b4a1fb792f4bc9824686a4b ] Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails. Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted. The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics. Fixes: acbdad8dd1ab ("serial: 8250_dw: simplify optional reset handling") Cc: stable Signed-off-by: Artem Shimko Link: https://patch.msgid.link/20251019095131.252848-1-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3299a39f9a091a699fd5fb2d2582a926685d8b8b Author: Andy Shevchenko Date: Mon Oct 27 13:31:44 2025 -0400 serial: 8250_dw: Use devm_add_action_or_reset() [ Upstream commit 295b09128d12fb1a7a67f771cc0ae0df869eafaf ] Slightly simplify ->probe() and drop a few goto labels by using devm_add_action_or_reset() for clock and reset cleanup. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220509172129.37770-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: daeb4037adf7 ("serial: 8250_dw: handle reset control deassert error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d979639f099c6e51f06ce4dd8d8e56364d6c17ba Author: Alexey Klimov Date: Wed Oct 22 21:10:12 2025 +0100 regmap: slimbus: fix bus_context pointer in regmap init calls commit 434f7349a1f00618a620b316f091bd13a12bc8d2 upstream. Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two "Fixes" tags. While at this, also correct the same argument in __regmap_init_slimbus(). Fixes: 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Cc: stable@vger.kernel.org Cc: Dmitry Baryshkov Cc: Ma Ke Cc: Steev Klimaszewski Cc: Srinivas Kandagatla Reviewed-by: Abel Vesa Signed-off-by: Alexey Klimov Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20251022201013.1740211-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c5279b8c91c94de50efe98987ea54f5f9bf1bfbc Author: Damien Le Moal Date: Mon Oct 27 09:27:32 2025 +0900 block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL commit 12a1c9353c47c0fb3464eba2d78cdf649dee1cf7 upstream. REQ_OP_ZONE_RESET_ALL is a zone management request. Fix op_is_zone_mgmt() to return true for that operation, like it already does for REQ_OP_ZONE_RESET. While no problems were reported without this fix, this change allows strengthening checks in various block device drivers (scsi sd, virtioblk, DM) where op_is_zone_mgmt() is used to verify that a zone management command is not being issued to a regular block device. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c674a191ada352b2038675d00029e7f22fc95ed1 Author: John Smith Date: Tue Oct 21 11:09:09 2025 +0200 drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland [ Upstream commit 501672e3c1576aa9a8364144213c77b98a31a42c ] Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.") Signed-off-by: John Smith Signed-off-by: Alex Deucher (cherry picked from commit 92b0a6ae6672857ddeabf892223943d2f0e06c97) Signed-off-by: Sasha Levin commit f64e5bdde3be4f212342cce09608608b4f3ad5f1 Author: John Smith Date: Tue Oct 21 11:08:13 2025 +0200 drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji [ Upstream commit 07a13f913c291d6ec72ee4fc848d13ecfdc0e705 ] Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18edef19ea44 ("drm/amd/powerplay: implement fw image related smu interface for Fiji.") Signed-off-by: John Smith Signed-off-by: Alex Deucher (cherry picked from commit c52238c9fb414555c68340cd80e487d982c1921c) Signed-off-by: Sasha Levin commit ca8cc1ae14252f3d9c8abad3a3e9f91bd09bc3b1 Author: Yang Wang Date: Wed Oct 22 14:12:21 2025 +0800 drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table() [ Upstream commit 238d468d3ed18a324bb9d8c99f18c665dbac0511 ] 'table_index' is a variable defined by the smu driver (kmd) 'table_id' is a variable defined by the hw smu (pmfw) This code should use table_index as a bounds check. Fixes: caad2613dc4bd ("drm/amd/powerplay: move table setting common code to smu_cmn.c") Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit fca0c66b22303de0d1d6313059baf4dc960a4753) Signed-off-by: Sasha Levin commit e5e712518b2968bbbdcbeb30ac50d62908d25f38 Author: Jijie Shao Date: Thu Oct 23 21:13:37 2025 +0800 net: hns3: return error code when function fails [ Upstream commit 03ca7c8c42be913529eb9f188278114430c6abbd ] Currently, in hclge_mii_ioctl(), the operation to read the PHY register (SIOCGMIIREG) always returns 0. This patch changes the return type of hclge_read_phy_reg(), returning an error code when the function fails. Fixes: 024712f51e57 ("net: hns3: add ioctl support for imp-controlled PHYs") Signed-off-by: Jijie Shao Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20251023131338.2642520-2-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8814f060d364d9eceb806f35aacbb07a8e31324d Author: Tomeu Vizoso Date: Tue Oct 21 11:37:23 2025 +0200 drm/etnaviv: fix flush sequence logic [ Upstream commit a042beac6e6f8ac1e923784cfff98b47cbabb185 ] The current logic uses the flush sequence from the current address space. This is harmless when deducing the flush requirements for the current submit, as either the incoming address space is the same one as the currently active one or we switch context, in which case the flush is unconditional. However, this sequence is also stored as the current flush sequence of the GPU. If we switch context the stored flush sequence will no longer belong to the currently active address space. This incoherency can then cause missed flushes, resulting in translation errors. Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling") Signed-off-by: Tomeu Vizoso Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Link: https://lore.kernel.org/r/20251021093723.3887980-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin commit 43005002b60ef3424719ecda16d124714b45da3b Author: Lizhi Xu Date: Wed Oct 22 10:40:07 2025 +0800 usbnet: Prevents free active kevent [ Upstream commit 420c84c330d1688b8c764479e5738bbdbf0a33de ] The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev(). Fixes: a69e617e533e ("usbnet: Fix linkwatch use-after-free on disconnect") Reported-by: Sam Sun Closes: https://syzkaller.appspot.com/bug?extid=8bfd7bcc98f7300afb84 Signed-off-by: Lizhi Xu Link: https://patch.msgid.link/20251022024007.1831898-1-lizhi.xu@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18652ab01a20aae4fdc6d1f9c38634e20528bb5d Author: Andrii Nakryiko Date: Mon Oct 20 13:36:43 2025 -0700 libbpf: Fix powerpc's stack register definition in bpf_tracing.h [ Upstream commit 7221b9caf84b3294688228a19273d74ea19a2ee4 ] retsnoop's build on powerpc (ppc64le) architecture ([0]) failed due to wrong definition of PT_REGS_SP() macro. Looking at powerpc's implementation of stack unwinding in perf_callchain_user_64() clearly shows that stack pointer register is gpr[1]. Fix libbpf's definition of __PT_SP_REG for powerpc to fix all this. [0] https://kojipkgs.fedoraproject.org/work/tasks/1544/137921544/build.log Fixes: 138d6153a139 ("samples/bpf: Enable powerpc support") Signed-off-by: Andrii Nakryiko Reviewed-by: Naveen N Rao (AMD) Link: https://lore.kernel.org/r/20251020203643.989467-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e5996b15ab1da32f065982a1b65dcee2db4c5d33 Author: Andrii Nakryiko Date: Wed Dec 22 13:39:23 2021 -0800 libbpf: Normalize PT_REGS_xxx() macro definitions [ Upstream commit 3cc31d794097a0de5ac619d4a20b1975139e6b05 ] Refactor PT_REGS macros definitions in bpf_tracing.h to avoid excessive duplication. We currently have classic PT_REGS_xxx() and CO-RE-enabled PT_REGS_xxx_CORE(). We are about to add also _SYSCALL variants, which would require excessive copying of all the per-architecture definitions. Instead, separate architecture-specific field/register names from the final macro that utilize them. That way for upcoming _SYSCALL variants we'll be able to just define x86_64 exception and otherwise have one common set of _SYSCALL macro definitions common for all architectures. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Tested-by: Ilya Leoshkevich Acked-by: Yonghong Song Acked-by: Ilya Leoshkevich Link: https://lore.kernel.org/bpf/20211222213924.1869758-1-andrii@kernel.org Stable-dep-of: 7221b9caf84b ("libbpf: Fix powerpc's stack register definition in bpf_tracing.h") Signed-off-by: Sasha Levin commit 82a674170040d6b52871df1c78726b1d8ed95e43 Author: Björn Töpel Date: Thu Oct 28 18:10:56 2021 +0200 riscv, libbpf: Add RISC-V (RV64) support to bpf_tracing.h [ Upstream commit 589fed479ba1e93f94d9772aa6162cd81f7e491c ] Add macros for 64-bit RISC-V PT_REGS to bpf_tracing.h. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20211028161057.520552-4-bjorn@kernel.org Stable-dep-of: 7221b9caf84b ("libbpf: Fix powerpc's stack register definition in bpf_tracing.h") Signed-off-by: Sasha Levin commit 9450d2fe01d00ac20f54f09d2db8b94089a1a00e Author: Ondrej Mosnacek Date: Tue Oct 21 14:27:58 2025 +0200 bpf: Do not audit capability check in do_jit() [ Upstream commit 881a9c9cb7856b24e390fad9f59acfd73b98b3b2 ] The failure of this check only results in a security mitigation being applied, slightly affecting performance of the compiled BPF program. It doesn't result in a failed syscall, an thus auditing a failed LSM permission check for it is unwanted. For example with SELinux, it causes a denial to be reported for confined processes running as root, which tends to be flagged as a problem to be fixed in the policy. Yet dontauditing or allowing CAP_SYS_ADMIN to the domain may not be desirable, as it would allow/silence also other checks - either going against the principle of least privilege or making debugging potentially harder. Fix it by changing it from capable() to ns_capable_noaudit(), which instructs the LSMs to not audit the resulting denials. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2369326 Fixes: d4e89d212d40 ("x86/bpf: Call branch history clearing sequence on exit") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20251021122758.2659513-1-omosnace@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit de2ce6b14bc3e565708a39bdba3ef9162aeffc72 Author: Noorain Eqbal Date: Mon Oct 20 23:33:01 2025 +0530 bpf: Sync pending IRQ work before freeing ring buffer [ Upstream commit 4e9077638301816a7d73fa1e1b4c1db4a7e3b59c ] Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: syzbot+2617fc732430968b45d2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2617fc732430968b45d2 Tested-by: syzbot+2617fc732430968b45d2@syzkaller.appspotmail.com Signed-off-by: Noorain Eqbal Link: https://lore.kernel.org/r/20251020180301.103366-1-nooraineqbal@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 29b6987bdea36831521096712ba15d6a18f494b2 Author: Roy Vegard Ovesen Date: Sat Oct 18 19:18:22 2025 +0200 ALSA: usb-audio: fix control pipe direction [ Upstream commit 7963891f7c9c6f759cc9ab7da71406b4234f3dd6 ] Since the requesttype has USB_DIR_OUT the pipe should be constructed with usb_sndctrlpipe(). Fixes: 8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c") Signed-off-by: Roy Vegard Ovesen Link: https://patch.msgid.link/aPPL3tBFE_oU-JHv@ark Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ea48293df43b99c5de575aaff5ea502695981623 Author: Akhil P Oommen Date: Thu Sep 11 02:14:05 2025 +0530 drm/msm/a6xx: Fix GMU firmware parser [ Upstream commit b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ] Current parser logic for GMU firmware assumes a dword aligned payload size for every block. This is not true for all GMU firmwares. So, fix this by using correct 'size' value in the calculation for the offset for the next block's header. Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path") Signed-off-by: Akhil P Oommen Acked-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/674040/ Message-ID: <20250911-assorted-sept-1-v2-2-a8bf1ee20792@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 488f3206325e70b596594ee831960b3c7c9935e3 Author: Loic Poulain Date: Fri Sep 26 21:56:56 2025 +0200 wifi: ath10k: Fix memory leak on unsupported WMI command [ Upstream commit 2e9c1da4ee9d0acfca2e0a3d78f3d8cb5802da1b ] ath10k_wmi_cmd_send takes ownership of the passed buffer (skb) and has the responsibility to release it in case of error. This patch fixes missing free in case of early error due to unhandled WMI command ID. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Fixes: 553215592f14 ("ath10k: warn if give WMI command is not supported") Suggested-by: Jeff Johnson Signed-off-by: Loic Poulain Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250926195656.187970-1-loic.poulain@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 641e47ea28319e43dae976c37b22d97c16769c82 Author: Srinivas Kandagatla Date: Fri Oct 17 09:52:56 2025 +0100 ASoC: qdsp6: q6asm: do not sleep while atomic commit fdbb53d318aa94a094434e5f226617f0eb1e8f22 upstream. For some reason we ended up kfree between spinlock lock and unlock, which can sleep. move the kfree out of spinlock section. Fixes: a2a5d30218fd ("ASoC: qdsp6: q6asm: Add support to memory map and unmap") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20251017085307.4325-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cca3958c5565cd7d02a136dc5744ec6b45998a08 Author: Paolo Abeni Date: Tue Oct 28 09:16:54 2025 +0100 mptcp: restore window probe commit a824084b98d8a1dbd6e85d0842a8eb5e73467f59 upstream. Since commit 72377ab2d671 ("mptcp: more conservative check for zero probes") the MPTCP-level zero window probe check is always disabled, as the TCP-level write queue always contains at least the newly allocated skb. Refine the relevant check tacking in account that the above condition and that such skb can have zero length. Fixes: 72377ab2d671 ("mptcp: more conservative check for zero probes") Cc: stable@vger.kernel.org Reported-by: Geliang Tang Closes: https://lore.kernel.org/d0a814c364e744ca6b836ccd5b6e9146882e8d42.camel@kernel.org Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Tested-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251028-net-mptcp-send-timeout-v1-3-38ffff5a9ec8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 90d835caf3eb1e073b0f02eeb0d643008cdb4f58 Author: Miaoqian Lin Date: Mon Oct 27 16:43:37 2025 +0800 fbdev: valkyriefb: Fix reference count leak in valkyriefb_init commit eb53368f8d6e2dfba84c8a94d245719bcf9ae270 upstream. The of_find_node_by_name() function returns a device tree node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Found via static analysis. Fixes: cc5d0189b9ba ("[PATCH] powerpc: Remove device_node addrs/n_addr") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 9c78e8179a1439f2ab64096cf57dabfb08840ab2 Author: Florian Fuchs Date: Sun Oct 26 00:38:50 2025 +0200 fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS commit 5f566c0ac51cd2474e47da68dbe719d3acf7d999 upstream. Commit e24cca19babe ("sh: Kill off MAX_DMA_ADDRESS leftovers.") removed the define ONCHIP_NR_DMA_CHANNELS. So that the leftover reference needs to be replaced by CONFIG_NR_ONCHIP_DMA_CHANNELS to compile successfully with CONFIG_PVR2_DMA enabled. Signed-off-by: Florian Fuchs Reviewed-by: John Paul Adrian Glaubitz Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 55f60a72a178909ece4e32987e4c642ba57e1cf4 Author: Gokul Sivakumar Date: Mon Oct 13 15:58:19 2025 +0530 wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode commit 3776c685ebe5f43e9060af06872661de55e80b9a upstream. Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. Cc: stable@vger.kernel.org Fixes: 18e2f61db3b7 ("brcmfmac: P2P action frame tx") Signed-off-by: Gokul Sivakumar Acked-by: Arend van Spriel Link: https://patch.msgid.link/20251013102819.9727-1-gokulkumar.sivakumar@infineon.com [Cc stable] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit db5c9a162d2f42bcc842b76b3d935dcc050a0eec Author: Junjie Cao Date: Mon Oct 20 21:47:01 2025 +0800 fbdev: bitblit: bound-check glyph index in bit_putcs* commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream. bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot. Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2 Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com Signed-off-by: Junjie Cao Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bc78a4f51d548c1ccc3d1967c2b394bf687c86e9 Author: Yuhao Jiang Date: Wed Oct 22 15:07:04 2025 -0500 ACPI: video: Fix use-after-free in acpi_video_switch_brightness() commit 8f067aa59430266386b83c18b983ca583faa6a11 upstream. The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress") Cc: All applicable Signed-off-by: Yuhao Jiang Reviewed-by: Hans de Goede [ rjw: Changelog edit ] Link: https://patch.msgid.link/20251022200704.2655507-1-danisjiang@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4b05bd1d75d3b152aa249128663f2af745d09409 Author: Daniel Palmer Date: Fri Oct 24 18:37:15 2025 +0900 fbdev: atyfb: Check if pll_ops->init_pll failed commit 7073c7fc8d8ba47194e5fc58fcafc0efe7586e9b upstream. Actually check the return value from pll_ops->init_pll() as it can return an error. If the card's BIOS didn't run because it's not the primary VGA card the fact that the xclk source is unsupported is printed as shown below but the driver continues on regardless and on my machine causes a hard lock up. [ 61.470088] atyfb 0000:03:05.0: enabling device (0080 -> 0083) [ 61.476191] atyfb: using auxiliary register aperture [ 61.481239] atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27] [ 61.487569] atyfb: 512K SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK [ 61.496112] atyfb: Unsupported xclk source: 5. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daniel Palmer Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c7bf258321a1201f974be0f477f959a0ad1a4198 Author: Miaoqian Lin Date: Mon Oct 27 00:43:16 2025 +0800 net: usb: asix_devices: Check return value of usbnet_get_endpoints commit dc89548c6926d68dfdda11bebc1a5258bc41d887 upstream. The code did not check the return value of usbnet_get_endpoints. Add checks and return the error if it fails to transfer the error. Found via static anlaysis and this is similar to commit 07161b2416f7 ("sr9800: Add check for usbnet_get_endpoints"). Fixes: 933a27d39e0e ("USB: asix - Add AX88178 support and many other changes") Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Link: https://patch.msgid.link/20251026164318.57624-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 375fdd8993cecc48afa359728a6e70b280dde1c8 Author: Chuck Lever Date: Tue Sep 30 10:05:20 2025 -0400 NFSD: Fix crash in nfsd4_read_release() commit abb1f08a2121dd270193746e43b2a9373db9ad84 upstream. When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test. Fixes: 15a8b55dbb1b ("nfsd: call op_release, even when op_func returns an error") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5fa8b4382c01b79dcea625bf16175bdd39ae5e84 Author: Filipe Manana Date: Mon Sep 22 12:09:14 2025 +0100 btrfs: use smp_mb__after_atomic() when forcing COW in create_pending_snapshot() [ Upstream commit 45c222468d33202c07c41c113301a4b9c8451b8f ] After setting the BTRFS_ROOT_FORCE_COW flag on the root we are doing a full write barrier, smp_wmb(), but we don't need to, all we need is a smp_mb__after_atomic(). The use of the smp_wmb() is from the old days when we didn't use a bit and used instead an int field in the root to signal if cow is forced. After the int field was changed to a bit in the root's state (flags field), we forgot to update the memory barrier in create_pending_snapshot() to smp_mb__after_atomic(), but we did the change in commit_fs_roots() after clearing BTRFS_ROOT_FORCE_COW. That happened in commit 27cdeb7096b8 ("Btrfs: use bitfield instead of integer data type for the some variants in btrfs_root"). On the reader side, in should_cow_block(), we also use the counterpart smp_mb__before_atomic() which generates further confusion. So change the smp_wmb() to smp_mb__after_atomic(). In fact we don't even need any barrier at all since create_pending_snapshot() is called in the critical section of a transaction commit and therefore no one can concurrently join/attach the transaction, or start a new one, until the transaction is unblocked. By the time someone starts a new transaction and enters should_cow_block(), a lot of implicit memory barriers already took place by having acquired several locks such as fs_info->trans_lock and extent buffer locks on the root node at least. Nevertlheless, for consistency use smp_mb__after_atomic() after setting the force cow bit in create_pending_snapshot(). Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5a6f9727ae785e4023f68759b98fd80a1573619a Author: Filipe Manana Date: Wed Aug 27 12:10:28 2025 +0100 btrfs: always drop log root tree reference in btrfs_replay_log() [ Upstream commit 2f5b8095ea47b142c56c09755a8b1e14145a2d30 ] Currently we have this odd behaviour: 1) At btrfs_replay_log() we drop the reference of the log root tree if the call to btrfs_recover_log_trees() failed; 2) But if the call to btrfs_recover_log_trees() did not fail, we don't drop the reference in btrfs_replay_log() - we expect that btrfs_recover_log_trees() does it in case it returns success. Let's simplify this and make btrfs_replay_log() always drop the reference on the log root tree, not only this simplifies code as it's what makes sense since it's btrfs_replay_log() who grabbed the reference in the first place. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f5c926c9e7fe59105844814e24f4311512dda710 Author: Thorsten Blum Date: Mon Sep 1 17:01:44 2025 +0200 btrfs: scrub: replace max_t()/min_t() with clamp() in scrub_throttle_dev_io() [ Upstream commit a7f3dfb8293c4cee99743132d69863a92e8f4875 ] Replace max_t() followed by min_t() with a single clamp(). As was pointed by David Laight in https://lore.kernel.org/linux-btrfs/20250906122458.75dfc8f0@pumpkin/ the calculation may overflow u32 when the input value is too large, so clamp_t() is not used. In practice the expected values are in range of megabytes to gigabytes (throughput limit) so the bug would not happen. Signed-off-by: Thorsten Blum Reviewed-by: David Sterba [ Use clamp() and add explanation. ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a740e71c23444af84fa500c32e4f6f68025310db Author: David Kaplan Date: Mon Sep 15 08:47:05 2025 -0500 x86/bugs: Fix reporting of LFENCE retpoline [ Upstream commit d1cc1baef67ac6c09b74629ca053bf3fb812f7dc ] The LFENCE retpoline mitigation is not secure but the kernel prints inconsistent messages about this fact. The dmesg log says 'Mitigation: LFENCE', implying the system is mitigated. But sysfs reports 'Vulnerable: LFENCE' implying the system (correctly) is not mitigated. Fix this by printing a consistent 'Vulnerable: LFENCE' string everywhere when this mitigation is selected. Signed-off-by: David Kaplan Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com Signed-off-by: Sasha Levin commit 1bed56f089f09b465420bf23bb32985c305cfc28 Author: Xiang Mei Date: Sat Jul 5 14:21:43 2025 -0700 net/sched: sch_qfq: Fix null-deref in agg_dequeue commit dd831ac8221e691e9e918585b1003c7071df0379 upstream. To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing. Signed-off-by: Xiang Mei Reviewed-by: Cong Wang Link: https://patch.msgid.link/20250705212143.3982664-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman