commit 587461ddf5d522bfcb50ebd55078c0dac37be496 Author: Greg Kroah-Hartman Date: Sat Oct 3 12:25:05 2026 +0200 Linux 5.10.271 Link: https://lore.kernel.org/r/20260930152347.700140858@linuxfoundation.org Tested-by: Woody Suwalski Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Brett A C Sheffield Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 1c380a332e342b7d58c86c4f556cb0823b16a9b8 Author: Pengpeng Hou Date: Mon Jul 6 17:27:52 2026 +0800 can: ems_usb: validate CPC message lengths commit 02925f51377f2a42a6724f00549167499c9302e5 upstream. ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706092752.79600-1-pengpeng@iscas.ac.cn Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde [Denis Arefev: adapted for 5.10: use get_can_dlc() instead of can_cc_dlc2len(), the latter was introduced in 6.x along with include/linux/can/length.h; get_can_dlc() has identical semantics for classic CAN frames (min(dlc, CAN_MAX_DLEN))] Signed-off-by: Denis Arefev Signed-off-by: Greg Kroah-Hartman commit 0b52e3192181b4de58844faedd2928e5c6ca0e06 Author: Guangshuo Li Date: Thu Sep 18 18:57:05 2025 +0800 drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() commit cc9a8e238e42c1f43b98c097995137d644b69245 upstream. kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher [ Roman: added parentheses to the 'if' statement, matching the upstream commit. ] Signed-off-by: Roman Demidov Signed-off-by: Greg Kroah-Hartman commit 4ed8d558d86461a9f7f39a3f10c1a0e1f9194ad7 Author: Rengarajan S Date: Wed May 29 19:32:56 2024 +0530 lan78xx: Enable Auto Speed and Auto Duplex configuration for LAN7801 if NO EEPROM is detected commit 799f532de13601f91ecb9cc6169d45d6e6933b0f upstream. Enabled ASD/ADD configuration for LAN7801 in the absence of EEPROM. After the lite reset these contents go back to defaults where ASD/ ADD is disabled. The check is already available for LAN7800. Reviewed-by: Simon Horman Signed-off-by: Rengarajan S Link: https://lore.kernel.org/r/20240529140256.1849764-3-rengarajan.s@microchip.com Signed-off-by: Jakub Kicinski Cc: Minh Tiến Nguyễn Signed-off-by: Greg Kroah-Hartman commit a551d993b504daa3f2f6e0cf9628f556b37df6d8 Author: Rengarajan S Date: Wed May 29 19:32:55 2024 +0530 lan78xx: Enable 125 MHz CLK configuration for LAN7801 if NO EEPROM is detected commit 5160b129f65fc6e1a4aa282d44f824e12aa800ee upstream. The 125MHz and 25MHz clock configurations are enabled in the initialization regardless of EEPROM (125MHz is needed for RGMII 1000Mbps operation). After a lite reset (lan78xx_reset), these contents go back to defaults(all 0, so no 125MHz or 25MHz clock). Reviewed-by: Simon Horman Signed-off-by: Rengarajan S Link: https://lore.kernel.org/r/20240529140256.1849764-2-rengarajan.s@microchip.com Signed-off-by: Jakub Kicinski Cc: Minh Tiến Nguyễn Signed-off-by: Greg Kroah-Hartman commit c3aee3fc1287c8a555baf3895959087cb0c33fe8 Author: Hui Peng Date: Sat Sep 19 11:25:18 2026 +0000 Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO commit 46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1 upstream. The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not connected as long as deferred setup is enabled: if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) { err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk; dlc->defer_setup is set in rfcomm_sock_init() when rfcomm_connect_ind() creates a child socket for an incoming connection on a listening socket that has BT_DEFER_SETUP enabled. It is never cleared afterwards. The session, however, can go away underneath it. rfcomm_recv_disc() forces the dlc state before tearing it down: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); The RFCOMM_DEFER_SETUP early return in __rfcomm_dlc_close() only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2, so with the state already BT_CLOSED that switch does not match and the function falls through to rfcomm_dlc_unlink(), which sets d->session = NULL, while d->defer_setup stays 1. A getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket after that point therefore skips the -ENOTCONN path -- sk->sk_state is BT_CLOSED, but dlc->defer_setup is still set -- and dereferences the NULL session. No race is needed: once the DISC has been processed, the dereference is unconditional. Reproduced on a KASAN kernel under QEMU with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session and sends SABM for a channel bound with BT_DEFER_SETUP, and sends DISC for that dlci after the socket has been accepted. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket then hits: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 0x10 is the offset of sock in struct rfcomm_session; rfcomm_sock_getsockopt_old() is inlined into rfcomm_sock_getsockopt(). Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") fixed the same "a remote DISC clears the session while deferred setup is still flagged" problem in rfcomm_dlc_accept(); this is the remaining instance of it, in the getsockopt path. Deferred setup only leaves a socket usable here once it has reached BT_CONNECT2, so restrict the exception to that state and check that a session is actually present before following it. Fixes: bb23c0ab8246 ("Bluetooth: Add support for deferring RFCOMM connection setup") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hui Peng Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 4373ba79a267947e771c438507f7b103e30bdb21 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:02:39 2026 -0300 Bluetooth: L2CAP: validate frame length before control and FCS access commit 6c78a213d9070b610c7f418af2c25b66180b7e37 upstream. l2cap_data_rcv() unpacks either a two-byte or four-byte control field without first ensuring that it is present. A short ERTM or streaming-mode frame can therefore cause an out-of-bounds read. There is a second short-frame case when CRC16 is enabled. After the control field is pulled, l2cap_check_fcs() subtracts two from skb->len without checking it. If fewer than two bytes remain, the subtraction wraps; skb_trim() leaves the buffer unchanged and the subsequent FCS load reads past the logical end of the frame. Validate that the frame contains both its control field and, when enabled, its FCS before either field is accessed. Fixes: 1c2acffb76d4 ("Bluetooth: Add initial support for ERTM packets transfers") Fixes: fcc203c30d72 ("Bluetooth: Add support for FCS option to L2CAP") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 70b0a27bdde0cb524349c8261202c7c9393cf5e9 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:03:58 2026 -0300 Bluetooth: hci_sock: reject out-of-range OCF values commit e93fad891c72deb84cae49430163b384ebcc92b1 upstream. The raw HCI socket security filter has 128 OCF bits per supported OGF, but masks the 10-bit OCF with 127 before looking up the command. An unprivileged socket can therefore submit a reserved OCF that aliases an allowlisted command modulo 128. A conforming controller should reject reserved opcodes. Nevertheless, the security decision must apply to the opcode that will actually be sent, especially since controller-specific behavior is outside the host stack's control. Reject OCF values that cannot be represented by the security filter instead of aliasing them onto an unrelated command. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 39e99d85071bca0feeec3164a9437ca1bff297fc Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:03:07 2026 -0300 Bluetooth: hci_sock: validate event length before filtering commit b0a6cf99afd57a39598b1beca0e86ef5004980de upstream. is_filtered_packet() reads the event code from skb->data[0] without first checking that the skb is nonempty. When an opcode filter is configured, it also reads the command opcode at offsets 3 or 4 without checking that a Command Complete or Command Status event is long enough. hci_send_to_sock() invokes the filter before hci_event_packet() validates the event header. A malformed event supplied by a controller or a vhci device can therefore cause an out-of-bounds read. Keep the unmasked event code for the opcode checks. The masked value is needed for the 64-bit event bitmap, but using it to identify command events aliases event codes above 0x3f. In particular, Synchronous Train Complete (0x4f) was treated as Command Status (0x0f) even though its payload has no opcode. Reject actual command events that are too short for the field being inspected. A truncated command event cannot match a configured opcode. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 9d8b21820caed9128945fffcedf03e2a4c21eee2 Author: Vineeth Vijayan Date: Tue Sep 22 22:48:39 2026 +0200 s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str() commit 5b76268dac968612f7283d59b539036de955b7d9 upstream. The channel path registry entry associated with a CHPID may be removed while the subchannel's PMCW still references that CHPID. In this case, chpid_to_chp() can return NULL, leading to a NULL pointer dereference. Add the missing NULL check before dereferencing the returned pointer. Fixes: 199652309a4d ("s390/cio: add helper to query utility strings per given ccw device") Cc: stable@vger.kernel.org Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 693e5be18f37139bd11ccdcd23a38f08ebe97de5 Author: Myeonghun Pak Date: Sun Sep 13 00:03:12 2026 -0400 pinctrl: single: free the IRQ on domain creation failure commit 1d9bb9c870632adea249cfdec49ac37e6f069164 upstream. pcs_irq_init_chained_handler() requests a shared IRQ on affected SoCs, but its domain creation failure path only removes a chained handler. That does not release the action installed by request_irq(). The probe can continue without interrupt support while leaving the shared IRQ action registered. Use pcs_irq_free() to undo the appropriate type of handler registration. At this point pcs->domain is NULL, so the helper only releases the parent IRQ handler. Then mark the IRQ invalid, as the other initialization error paths already do, to prevent another release from a later probe unwind or remove. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 3e6cee1786a1 ("pinctrl: single: Add support for wake-up interrupts") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 79991b770fc3685b1d5cf805b659a879edd19931 Author: Yehyeong Lee Date: Sat Aug 1 22:36:35 2026 +0900 scsi: libiscsi_tcp: Check the data direction of a Data-In PDU commit bce07e2f37b5e4a427d36fd6b1c14067b27591db upstream. The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task and copies the PDU's data segment into that command's scatterlist without asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE. A target that answers a WRITE command's ITT with a Data-In therefore has the initiator write target-supplied bytes into the pages that write was about to send. Those are the caller's own pinned pages for an O_DIRECT write, and page cache pages for a buffered one. Observed against a test target that emits one 512-byte Data-In naming a 128 KB write's ITT, after the R2T for that write. With O_DIRECT the caller's buffer ends up holding 512 bytes of the target's data while pwrite() returns 131072. Buffered is quieter: pwrite() and fsync() both succeed, nothing is logged, and reading those blocks back returns the target's bytes out of the page cache without a command going on the wire. Check the direction before using the scatterlist, the way the R2T path already does. Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260801133635.1986706-1-yhlee@isslab.korea.ac.kr Fixes: a081c13e39b5 ("[SCSI] iscsi_tcp: split module into lib and lld") Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 0d482995f0cdd0302450aa300c684c642d8ab31f Author: Doruk Tan Ozturk Date: Sat Jul 11 14:36:51 2026 +0200 nfc: port100: reject frames whose declared length exceeds the received data commit 092c6a605cbd6414ef499834c2e0da69c2c3388e upstream. port100_recv_response() passes the URB transfer buffer to port100_rx_frame_is_valid(), which checksums le16_to_cpu(frame->datalen) bytes of frame->data. datalen is a 16-bit field supplied by the device and is never checked against the number of bytes actually received (urb->actual_length), so a device reporting a datalen larger than the received frame makes port100_data_checksum() read out of bounds past the transfer buffer. Reject a response whose declared frame size does not fit the received length before validating it. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested. Fixes: 562d4d59b8a1 ("NFC: Sony Port-100 Series driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260711123651.32595-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 3afdbebfee2ef7e9510880868cfb482cbffe6836 Author: Aamir Ahmed Date: Tue Sep 15 19:54:27 2026 +0100 nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() commit 273f9d667cde649f8de9d72b1303cc2f4b658c50 upstream. nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 ("nfc: llcp: reject PDUs shorter than the LLCP header") did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply. Fixes: d646960f7986 ("NFC: Initial LLCP support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Simon Horman Link: https://patch.msgid.link/AS8P251MB0001789BBF04B72745C7D96BC8BA2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 25bfa673adc70189c0bc872940421ae59f789cf6 Author: Luxiao Xu Date: Wed Sep 9 13:19:24 2026 +0800 nfc: fix use-after-free in nfc_get_local_general_bytes commit dcab71a7011918f6fdba7adcec02d217dcb84b8d upstream. Commit 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local") attempted to fix a use-after-free (UAF) issue by invoking nfc_llcp_local_put(local) after accessing local->gb. However, if the reference count drops to zero, local is freed immediately, leading to a use-after-free when callers access the returned pointer. Alternative approaches using dynamic allocation (e.g. kmemdup) introduced memory leaks because callers consistently treat the returned pointer as borrowed memory. Fix this properly by refactoring nfc_llcp_general_bytes() and nfc_get_local_general_bytes() to accept a caller-provided output buffer (out_gb) and its maximum length (gb_max_len). The general bytes are safely copied into out_gb before calling nfc_llcp_local_put(local), ensuring safe lifetime management without ownership transfer complications. Update all callers across drivers (microread, pn533, pn544, st21nfca, digital_dep, and nci) to provide their own destination buffers and pass them to nfc_get_local_general_bytes(). Fixes: 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/3cbaac3bee23f8ff3a3284ed32d347696eb1d208.1788841683.git.rakukuip@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 959d1829d1ce8b91b435b24a923b51bcc8897090 Author: Luxiao Xu Date: Sun Sep 6 21:29:55 2026 +0800 netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read commit 82313c169eddc02b1bf5ba6b427803e272d3ec42 upstream. rt_mt6_check() permits rules to be configured with rtinfo->addrnr == 0 even when address matching (IP6T_RT_FST_MASK) is requested. In the IP6T_RT_FST_NSTRICT path, rt_mt6() evaluates packet routing addresses against rtinfo->addrs[i] and terminates backwards at the bottom of the loop: if (ipv6_addr_equal(ap, &rtinfo->addrs[i])) { i++; } if (i == rtinfo->addrnr) break; When addrnr is 0, if the first packet address matches rtinfo->addrs[0], i is incremented to 1. Because i is now strictly greater than addrnr (0), the loop termination condition (i == rtinfo->addrnr) is bypassed and will never be satisfied. If a crafted IPv6 packet contains matching routing addresses, i will advance past IP6T_RT_HOPS (16). The subsequent call to ipv6_addr_equal() reads beyond struct ip6t_rt, triggering UBSAN/KASAN out-of-bounds warnings or kernel panics. Fix this by: 1. Rejecting rules in rt_mt6_check() where IP6T_RT_FST_MASK is set but rtinfo->addrnr is zero. 2. In rt_mt6(), moving the termination condition (i < rtinfo->addrnr) into the for-loop header condition and removing the backwards break at the end of the loop body. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Florian Westphal Assisted-by: LLM Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit f4de78756b0fddbd125b2b1b77c74f2eccc8e977 Author: Weiming Shi Date: Sun Sep 6 16:44:10 2026 +0800 netfilter: ip6t_rpfilter: reject routes without inet6_dev commit 1b9b5323725e458906c7620a3bc10398b51ad954 upstream. ip6_route_lookup() can return an error-free route whose rt6i_idev is NULL. Lowering an external nexthop device's MTU below IPV6_MIN_MTU tears down its inet6_dev while fib6_ifdown() leaves routes using nexthop objects in the FIB. An unprivileged user can construct this state with rtnetlink in a private user and network namespace, then trigger a NULL dereference through an IPv6 rpfilter lookup: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: rpfilter_mt (net/ipv6/netfilter/ip6t_rpfilter.c:75) Call Trace: ip6t_do_table (net/ipv6/netfilter/ip6_tables.c:316) nf_hook_slow (net/netfilter/core.c:619) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6216) process_backlog (net/core/dev.c:6680) __napi_poll (net/core/dev.c:7739) net_rx_action (net/core/dev.c:7959) handle_softirqs (kernel/softirq.c:622) do_softirq.part.0 (kernel/softirq.c:523) __local_bh_enable_ip (kernel/softirq.c:450) __dev_queue_xmit (net/core/dev.c:4913) packet_sendmsg (net/packet/af_packet.c:3139) __sys_sendto (net/socket.c:2252) __x64_sys_sendto (net/socket.c:2259) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Reject routes without an inet6_dev immediately after lookup. Such routes are not eligible for reverse-path filtering, and the check protects all later rt6i_idev dereferences. Fixes: e26f9a480fb6 ("netfilter: add ipv6 reverse path filter match") Reported-by: co+459f67f4d8af8ce6@bugs.sh Closes: https://lore.kernel.org/all/VtWUkE8QzJt5CroTj2V2v3ZQ0gwbXZ7nq7I3@bugs.sh/ Suggested-by: Florian Westphal Assisted-by: Claude:gpt-5 Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 90e64f6694d856c0738ea3b794b8ff10988cfc4b Author: Ming Wang Date: Sun Sep 20 15:44:59 2026 +0800 net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist commit f75f21ef36285e5f56ee0c428bd2909ee81165b9 upstream. The MeiG Smart SRM821 5G module (0x2dee:0x4d53) crashes and drops off the USB bus when it receives a Zero Length Packet (ZLP) after sending or receiving an NTB of exactly 16384 bytes (tx_max). According to the MBIM specification, devices do not require a ZLP if the NTB size is exactly dwNtbOutMaxSize. However, the cdc_mbim driver defaults to sending ZLPs for devices not explicitly whitelisted to accommodate non-conformant hardware. This default behavior breaks the strictly conformant MeiG SRM821 module. Add this device to the ZLP conformance whitelist (cdc_mbim_info) so the driver will pad the NTB to avoid sending ZLPs, preventing the device firmware from crashing. Cc: stable@vger.kernel.org Signed-off-by: Ming Wang Link: https://patch.msgid.link/20260920074500.826121-1-wangming01@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ca862b1a4af7eac19429ca7ab92625f94ff4a46c Author: Gajdos Tamás Date: Mon Sep 21 11:13:33 2026 +0200 net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read commit 374bf9e4b90f979e052332c4faca2d745c491a12 upstream. Same issue as atl1c (see the first commit in this series, "net: atl1c: fix soft lockup on out-of-range tpd_cons read"): the hardware can report an out-of-range hw_next_to_clean (seen as 0xffff) while the PCIe link/MAC is resetting. An out-of-range value can never be reached and the loop below would spin forever. Treat it as "nothing new to clean" instead. Fixes: a6a5325239c202 ("atl1e: Atheros L1E Gigabit Ethernet driver") Cc: stable@vger.kernel.org Signed-off-by: Gajdos Tamás Link: https://patch.msgid.link/20260921091334.3571525-3-tamas@rimpianto.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e7acd4cdeccbcdfd407adeb72b1eba14d1145b6f Author: Gajdos Tamás Date: Mon Sep 21 11:13:32 2026 +0200 net: atl1c: fix soft lockup on out-of-range tpd_cons read commit 36c2009d90f2210ef92e6f4f2850e8b57b09e754 upstream. The hardware can report an out-of-range tpd_cons (seen as 0xffff) while the PCIe link/MAC is resetting. An out-of-range value can never be reached and the loop below would spin forever. To avoid a soft lockup treat it as "nothing new to clean" instead. Reproduced on two machines, same NIC (Qualcomm Atheros AR8151 v2.0, 4-port), triggered by rebooting a Mikrotik CCR2004 PCIe card that the ports are directly linked to: - Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic. The link-flap precursor, before the lockup was captured with a full trace elsewhere: atl1c 0000:05:00.0 enp5s0f0: NETDEV WATCHDOG: CPU: 4: transmit queue 2 timed out 489984 ms atl1c 0000:05:00.0: MAC state machine can't be idle since disabled for 10ms second atl1c 0000:05:00.0: atl1c: enp5s0f0 NIC Link is Up<65535 Mbps Full Duplex> 65535 (0xffff) here is the same value tpd_cons reads back once the loop below gets stuck. - Proxmox VE, kernel 7.0.14-11-pve. Same NIC/trigger, this time caught by the soft lockup watchdog with a full stack trace: watchdog: BUG: soft lockup - CPU#12 stuck for 354s! [napi/eth%d-0:329] CPU: 12 UID: 0 PID: 329 Comm: napi/eth%d-0 Tainted: P O L 7.0.14-11-pve #1 PREEMPT(lazy) RIP: 0010:atl1c_clean_tx+0x142/0x2d0 [atl1c] Call Trace: __napi_poll+0x32/0x1e0 napi_threaded_poll_loop+0x286/0x2e0 napi_threaded_poll+0xfd/0x140 kthread+0xf7/0x130 ret_from_fork+0x2da/0x3a0 ret_from_fork_asm+0x1a/0x30 Fixes: 43250ddd75a35d ("atl1c: Atheros L1C Gigabit Ethernet driver") Cc: stable@vger.kernel.org Signed-off-by: Gajdos Tamás Link: https://patch.msgid.link/20260921091334.3571525-2-tamas@rimpianto.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e0fa5ea434b7e8467ef3adc64e3858b1ca2a642d Author: Ilya Maximets Date: Mon Sep 21 16:55:43 2026 +0200 net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry commit 26b2bd70d22457556e2fa01cbf1192cb1a94d619 upstream. In a case where skb with an unconfirmed ct entry gets cloned, we may end up committing both but with different sets of extensions. The series of events: 1. The first clone wants to commit and runs the helpers wiring up the extension pointer into the expectation list. 2. Then it looses the confirmation keeping the entry unconfirmed. 3. Second clone now wants to commit labels and adds the new extension for that breaking the pointer in the expectation list causing UAF on the destruction path later. While this is possible to trigger, there should be no practical network pipeline where committing both clones without modifications into the same zone is needed. So, let's just reset the entry in case for some reason we got an skb with a shared one during commit. This doesn't affect any known use cases, but avoids any potential problems with sharing and modification of the unconfirmed ct entry. The fixes tag points to the introduction of helpers, since that's the main UAF trigger for the sharing. Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action") Cc: stable@vger.kernel.org Reported-by: Axel Mierczuk Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260921145655.3167436-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fee0195eb15ccf6e448ce274b069140fb0b069a7 Author: Wentao Liang Date: Thu Sep 17 11:08:28 2026 +0000 net: hisilicon: hns_dsaf_mac: fix mdio device leak in hns_mac_register_phy() commit 999e8295bc41d6ce45b8e54f88150efa96f3f01e upstream. hns_dsaf_find_platform_device() returns the mdio platform device with its reference count incremented. hns_mac_register_phy() never drops that reference, so the mdio device can not be released. Release the reference on both the deferred probe and the normal path. Fixes: 1d1afa2ebf82 ("net: hns: register phy device in each mac initial sequence") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260917110828.2148390-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 5d7ac337d37cb97d77e4c910d37746694b606661 Author: Gajdos Tamás Date: Mon Sep 21 11:13:34 2026 +0200 net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read commit 43e746821f5f5afbbf68e388bf9fbe221e03bfca upstream. Same issue as atl1c (see the first commit in this series, "net: atl1c: fix soft lockup on out-of-range tpd_cons read"): the hardware can report an out-of-range cmb_tpd_next_to_clean (seen as 0xffff) while the PCIe link/MAC is resetting. An out-of-range value can never be reached and the loop below would spin forever. Treat it as "nothing new to clean" instead. Fixes: f3cc28c797604f ("Add Attansic L1 ethernet driver.") Cc: stable@vger.kernel.org Signed-off-by: Gajdos Tamás Link: https://patch.msgid.link/20260921091334.3571525-4-tamas@rimpianto.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ae6d704dbf9542b0a0830ec91a2db4f30307e7d8 Author: Zijie Huang Date: Mon Sep 21 01:36:19 2026 +0800 net: arp: terminate device name before lookup commit d8b6529e80bcb4fb8177121404cbb3377acaebd2 upstream. The ARP ioctl copies a user-provided struct arpreq into a stack object. Its arp_dev field may contain IFNAMSIZ bytes without a NUL terminator. Such input is passed to dev_get_by_name_rcu() or __dev_get_by_name(), where strcmp() can read past the end of the stack object when a matching alternative interface name exists. Terminate the field before the lookup to prevent the out-of-bounds read. Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zijie Huang Signed-off-by: Ren Wei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/fabf02a70787d17299e4b3153eadffaf20d154b3.1789910973.git.milkory@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 39b751a210bf61a374afa82749afc7a77a08bf1d Author: Weiming Shi Date: Mon Sep 14 14:51:23 2026 +0800 net/sched: reject IDR error pointers when deleting actions commit c82b797abe668d0b668601a93ba2c0b071a63574 upstream. tcf_action_delete() drops the reference held by its lookup before calling tcf_idr_delete_index() with the saved action index. An unlocked classifier can remove that action and reserve the same IDR slot with ERR_PTR(-EBUSY) in between. tcf_idr_delete_index() only checks the lookup result for NULL. It therefore treats the reservation as a tc_action and dereferences tcfa_bindcnt. A hardware execution breakpoint was used to schedule the interleaving without changing the kernel source. KASAN reported this decoded trace: BUG: KASAN: null-ptr-deref in tca_action_gd+0x5b9/0x1010 Read of size 4 at addr 0000000000000010 by task poc/150 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002 RIP: tca_action_gd+0x5c0/0x1010: arch_atomic_read at arch/x86/include/asm/atomic.h:23 raw_atomic_read at include/linux/atomic/atomic-arch-fallback.h:457 atomic_read at include/linux/atomic/atomic-instrumented.h:33 tcf_idr_delete_index at net/sched/act_api.c:766 tcf_action_delete at net/sched/act_api.c:1859 tcf_del_notify at net/sched/act_api.c:2014 tca_action_gd at net/sched/act_api.c:2064 R13: 0000000000000010 R15: fffffffffffffff0 Kernel panic - not syncing: Fatal exception R15 contains ERR_PTR(-EBUSY), and adding the tcfa_bindcnt offset produces the address in R13. With the guard applied, the same reproducer returned -ENOENT without a KASAN report or panic. Treat error pointers as absent and return -ENOENT. Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260914065123.4109709-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 598daa5f95883f881a54967da40ce0fdfc1fdaa8 Author: Wentao Liang Date: Thu Sep 17 11:31:31 2026 +0000 net/mlx5: Fix rev_entry reference leak in mlx5_tc_ct_shared_counter_get() commit 0bf6bb567f0edaa771e7dd208ef98da50e6a4485 upstream. When the reverse entry is found but its counter is already being released, refcount_inc_not_zero() fails and the reference taken by mlx5_tc_ct_entry_get() is never dropped before falling through to create_counter. Drop it so the reverse entry is not kept alive forever by a shared counter lookup that did not use it. Fixes: 1edae2335adf ("net/mlx5e: CT: Use the same counter for both directions") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260917113131.2149024-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9aa62f967b6a4bb30aa3b778e02c8a5ca6bcde51 Author: Wei Jie LAW <98lawweijie@gmail.com> Date: Wed Sep 9 09:15:13 2026 +0800 HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce() commit 9aa237cf66495b2426ddde8532e9b08a0ed83aaa upstream. The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an invalid offset to hid_field_extract(), resulting in memory reads at incorrect addresses -- possibly beyond the end of the report. If a field in the HID descriptor lists more usages than its Report Count actually reserves space for, the function's inner 'j' will walk past the end of the field: for (i = 0; i < report->maxfield; i++) { for (j = 0; j < report->field[i]->maxusage; j++) { ... value = hid_field_extract(hdev, raw_data + 1, offset + j * size, size); A descriptor listing 12288 usages against Report Count 1 has the loop extract the usage at index 12287 from bit offset 98296 -- about 12 KB past a 2-byte received report. The value is stored in wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event, making this an information disclosure. Clamp the loop to field->report_count, the number of value slots the report holds. Value slots past the last declared usage are still scanned; they reuse that usage (HID 1.11, 6.2.2.8). Verified on v6.12.105 with a UHID reproducer: a 2-byte report from such a descriptor trips KASAN before the patch and not after it. Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing") Suggested-by: Jason Gerecke Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 15af34b8a2c9a09cdf49e211627745a8ee49d1b7 Author: Junjie Cao Date: Mon Aug 24 11:14:19 2026 +0800 HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard commit cdb669a3b8f844aca71fc3224990157d61562165 upstream. The SDINNOVATION gaming keyboard (USB ID 36ae:feab) stops reporting input events after its RGB lighting mode is switched about twice. Disabling USB autosuspend and unbinding the other HID interfaces make no difference; the issue does not occur on Windows. HID_QUIRK_ALWAYS_POLL alone resolves it, verified on 7.1.8 via usbhid.quirks=0x36ae:0xfeab:0x400. Reported-by: Marco Carvalho Link: https://bugzilla.redhat.com/show_bug.cgi?id=2514627 Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 64f824dccfd316fd3db8ea1cc4e8a76ad6a02740 Author: Chen Changcheng Date: Fri Aug 14 15:06:21 2026 +0800 HID: alps: fix use-after-free on input2 registration failure commit d3aba3442798ce4a4c8ce3104d7b286d61e605f9 upstream. alps_input_configured() stores data->input2 before calling input_register_device(). If registration fails, input_free_device() frees the input device but data->input2 still points to the freed memory. alps_input_configured() calls hid_hw_open() before allocating input2, so URBs are already active and raw_event can fire during the failure window. A U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event() to dereference the freed data->input2 -> use-after-free. Fix by only storing input2 into drvdata after successful registration and adding a NULL guard in the raw_event path. Fixes: 2562756dde55 ("HID: add Alps I2C HID Touchpad-Stick support") Cc: stable@vger.kernel.org Signed-off-by: Chen Changcheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit af2f48c12365866abb327d75c21a13bbde84719c Author: Wentao Liang Date: Wed Sep 16 18:02:02 2026 +0000 drm/nouveau: Fix gem reference leak in validate_init() commit 5ea72f7b7139b123713a7983448f910bc4514d9e upstream. On the ttm_bo_reserve() failure and "vma not found" error paths, the loop breaks without adding the looked-up object to any validate list, so the reference taken by drm_gem_object_lookup() is never released; validate_fini() only walks the spliced lists. Drop the reference before breaking out on both paths. Fixes: 19ca10d82e33bcfe ("drm/nouveau/gem: lookup VMAs for buffers referenced by pushbuf ioctl") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260916180202.2090231-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 023e7a01f8fb27799f0987b5bcda325d73a2904c Author: Peiyang He Date: Wed Sep 16 18:31:38 2026 +0800 drm/nouveau: fix double-free in nvif_vmm_dtor commit 97077ac87afe9e91ec074ef0be64454e7ccbf344 upstream. On failure, nouveau_cli_init() calls nouveau_cli_fini() to tear the client down. Then, nouveau_drm_open() also enters into its cleanup path and calls nouveau_cli_fini() AGAIN. nouveau_cli_fini() calls nouveau_vmm_fini(): void nouveau_vmm_fini(struct nouveau_vmm *vmm) { nouveau_svmm_fini(&vmm->svmm); nvif_vmm_dtor(&vmm->vmm); vmm->cli = NULL; } Inside nvif_vmm_dtor(), vmm->page is freed unconditionally: void nvif_vmm_dtor(struct nvif_vmm *vmm) { kfree(vmm->page); nvif_object_dtor(&vmm->object); } vmm->page is never cleared after being freed, so the second call of nvif_vmm_dtor() will cause a double-free. Found by fuzzing the nouveau driver with a modified Syzkaller: BUG: KASAN: double-free in nvif_vmm_dtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194 Free of addr ffff888010fcdc30 by task syz.0.173/2567 CPU: 1 UID: 0 PID: 2567 Comm: syz.0.173 Not tainted 7.2.0 #24 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x95/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcb/0x5a0 mm/kasan/report.c:482 kasan_report_invalid_free+0xaa/0xd0 mm/kasan/report.c:557 check_slab_allocation+0xe4/0x110 mm/kasan/common.c:235 kasan_slab_pre_free include/linux/kasan.h:199 [inline] slab_free_hook mm/slub.c:2622 [inline] slab_free mm/slub.c:6377 [inline] kfree+0x192/0x590 mm/slub.c:6692 nvif_vmm_dtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194 nouveau_vmm_fini+0x16/0x50 drivers/gpu/drm/nouveau/nouveau_vmm.c:127 nouveau_cli_fini+0x10e/0x210 drivers/gpu/drm/nouveau/nouveau_drm.c:225 nouveau_drm_open+0x24e/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1255 drm_file_alloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176 drm_open_helper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335 drm_open+0x190/0x3d0 drivers/gpu/drm/drm_file.c:388 drm_stub_open+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211 chrdev_open+0x21c/0x660 fs/char_dev.c:411 do_dentry_open+0x59d/0x12b0 fs/open.c:947 vfs_open+0x82/0x390 fs/open.c:1052 do_open fs/namei.c:4700 [inline] path_openat+0x2345/0x3420 fs/namei.c:4863 do_file_open+0x207/0x460 fs/namei.c:4892 do_sys_openat2+0xd1/0x1d0 fs/open.c:1368 do_sys_open fs/open.c:1374 [inline] __do_sys_openat fs/open.c:1390 [inline] __se_sys_openat fs/open.c:1385 [inline] __x64_sys_openat+0x144/0x200 fs/open.c:1385 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6d687594d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6d5295008 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007fc6d6b06180 RCX: 00007fc6d687594d RDX: 0000000000022501 RSI: 0000200000000000 RDI: ffffffffffffff9c RBP: 00007fc6d691c303 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fc6d6b06218 R14: 00007fc6d6b06180 R15: 00007ffd9451d760 Allocated by task 2567 on cpu 1 at 163.593900s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5334 [inline] __kmalloc_noprof+0x304/0x7c0 mm/slub.c:5359 _kmalloc_noprof include/linux/slab.h:992 [inline] nvif_vmm_ctor+0x3c0/0x7e0 drivers/gpu/drm/nouveau/nvif/vmm.c:237 nouveau_vmm_init+0x40/0x90 drivers/gpu/drm/nouveau/nouveau_vmm.c:134 nouveau_cli_init+0x7b9/0xe10 drivers/gpu/drm/nouveau/nouveau_drm.c:293 nouveau_drm_open+0x236/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1243 drm_file_alloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176 drm_open_helper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335 drm_open+0x190/0x3d0 drivers/gpu/drm/drm_file.c:388 drm_stub_open+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211 chrdev_open+0x21c/0x660 fs/char_dev.c:411 do_dentry_open+0x59d/0x12b0 fs/open.c:947 vfs_open+0x82/0x390 fs/open.c:1052 do_open fs/namei.c:4700 [inline] path_openat+0x2345/0x3420 fs/namei.c:4863 do_file_open+0x207/0x460 fs/namei.c:4892 do_sys_openat2+0xd1/0x1d0 fs/open.c:1368 do_sys_open fs/open.c:1374 [inline] __do_sys_openat fs/open.c:1390 [inline] __se_sys_openat fs/open.c:1385 [inline] __x64_sys_openat+0x144/0x200 fs/open.c:1385 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 2567 on cpu 1 at 163.601355s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x61/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2677 [inline] slab_free mm/slub.c:6377 [inline] kfree+0x383/0x590 mm/slub.c:6692 nvif_vmm_dtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194 nouveau_vmm_fini+0x16/0x50 drivers/gpu/drm/nouveau/nouveau_vmm.c:127 nouveau_cli_fini+0x10e/0x210 drivers/gpu/drm/nouveau/nouveau_drm.c:225 nouveau_cli_init+0x593/0xe10 drivers/gpu/drm/nouveau/nouveau_drm.c:324 nouveau_drm_open+0x236/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1243 drm_file_alloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176 drm_open_helper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335 drm_open+0x190/0x3d0 drivers/gpu/drm/drm_file.c:388 drm_stub_open+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211 chrdev_open+0x21c/0x660 fs/char_dev.c:411 do_dentry_open+0x59d/0x12b0 fs/open.c:947 vfs_open+0x82/0x390 fs/open.c:1052 do_open fs/namei.c:4700 [inline] path_openat+0x2345/0x3420 fs/namei.c:4863 do_file_open+0x207/0x460 fs/namei.c:4892 do_sys_openat2+0xd1/0x1d0 fs/open.c:1368 do_sys_open fs/open.c:1374 [inline] __do_sys_openat fs/open.c:1390 [inline] __se_sys_openat fs/open.c:1385 [inline] __x64_sys_openat+0x144/0x200 fs/open.c:1385 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888010fcdc30 which belongs to the cache kmalloc-16 of size 16 The buggy address is located 0 bytes inside of 16-byte region [ffff888010fcdc30, ffff888010fcdc40) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10fcd flags: 0x100000000000000(node=0|zone=1) page_type: f5(slab) raw: 0100000000000000 ffff88800d441640 dead000000000100 dead000000000122 raw: 0000000000000000 0000000000550055 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888010fcdb00: fc fc 00 04 fc fc fc fc fa fb fc fc fc fc fa fb ffff888010fcdb80: fc fc fc fc fa fb fc fc fc fc 00 07 fc fc fc fc >ffff888010fcdc00: fa fb fc fc fc fc fa fb fc fc fc fc fa fb fc fc ^ ffff888010fcdc80: fc fc fa fb fc fc fc fc 00 04 fc fc fc fc fa fb ffff888010fcdd00: fc fc fc fc 00 00 fc fc fc fc fa fb fc fc fc fc Fix by removing the redundant teardown in nouveau_drm_open(), since nouveau_cli_init() already does the cleanup work. Also clear vmm->page after its freeing. Cc: stable@vger.kernel.org Fixes: 20d8a88e557a ("drm/nouveau: tidy up the client init/fini interfaces") Signed-off-by: Peiyang He Assisted-by: LLM Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/03BA723D9E5FF725+20260916103138.2651605-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Greg Kroah-Hartman commit add5e0a45e3971df9c65cc7b59c90559a25dc5a9 Author: Wentao Liang Date: Wed Sep 16 18:00:36 2026 +0000 drm/nouveau: Fix bridge reference leak in nv1a_ram_new() commit 67b4411538c8341692548429d43256f25be99f7a upstream. pci_get_domain_bus_and_slot() takes a reference to the PCI device, which is never released once the memory size has been read from its config space. Drop the reference before returning. Fixes: 2fa6d6cdaf283c05 ("drm/nouveau: deprecate pci_get_bus_and_slot()") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260916180036.2090118-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 7ae79134966480e295c9dbe1cbb68c2d001bfe47 Author: Guangshuo Li Date: Sat Aug 8 21:41:37 2026 +0800 drm/nouveau: fix autosuspend cleanup during teardown commit fefd9480ec361969f1a836df46326a1801062c26 upstream. nouveau_drm_device_init() calls pm_runtime_use_autosuspend(), but nouveau_drm_device_fini() does not call the matching pm_runtime_dont_use_autosuspend(). If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the common device teardown path. This issue was found by manual code inspection. Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260808134137.2864847-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1be3211e6ac77adbb1eac01314d989d243b32c59 Author: Dongliang Qin Date: Tue Sep 22 11:15:45 2026 +0800 rds: ib: Clear the sg list when mapping an MR fails commit 58eb1b3325edac42dc6df72c80962bd53a3c8ca7 upstream. rds_ib_map_frmr() stores the caller's scatterlist in the MR before DMA mapping and registration can fail. On failure, __rds_rdma_map() unpins the pages and frees the scatterlist, but rds_ib_free_frmr() can still return the MR to the pool with the stale pointer set. This leaves the pool with a dangling scatterlist and can lead to local privilege escalation. KASAN detects the resulting use-after-free when the MR is later torn down: BUG: KASAN: slab-use-after-free in __rds_ib_teardown_mr Read of size 8 Call Trace: __rds_ib_teardown_mr rds_ib_unreg_frmr rds_ib_flush_mr_pool rds_ib_flush_mrs rds_free_mr rds_setsockopt Store the scatterlist in the MR only after DMA mapping succeeds. If DMA mapping fails, return directly while the MR fields remain clear; the caller keeps ownership of the scatterlist and its pinned pages. If a later registration step fails, unmap the scatterlist and clear the MR fields before returning. Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode") Cc: stable@vger.kernel.org Signed-off-by: Dongliang Qin Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260922031546.3874605-1-cccccccccccc777777@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 018020f5a48cc86fdd6dc2d380f6c70443ae7639 Author: Zixuan Chai Date: Thu Sep 24 09:26:05 2026 +0800 llc: reserve device headroom for allocated frames commit 72b5b9a28b996e09b8b5b944370c79851bb68f52 upstream. llc_alloc_frame() reserves link-layer headroom using the device type. This is insufficient for stacked Ethernet devices such as VLAN devices, where vlan_dev_hard_header() pushes a VLAN header before the lower device's Ethernet header. An LLC response on such a device can therefore underflow skb headroom in eth_header(). Use LL_RESERVED_SPACE() to account for the device's actual required headroom while preserving the existing LLC device-type check. Fixes: bf9ae5386bca ("llc: use dev_hard_header") Cc: stable@vger.kernel.org Reported-by: VEGA Signed-off-by: Zixuan Chai Signed-off-by: Ren Wei Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260924012613.2533934-1-weir@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e380fba02908b809f5bbef371259003cf5887bb4 Author: Ridham Khurana Date: Tue Sep 22 09:20:58 2026 +0000 gpio: zynq: fix runtime PM leak on request error path commit e9438ab5328a177c9c0e5df87eb92a7162841e98 upstream. pm_runtime_get_sync() leaves the usage counter incremented even when it fails, and zynq_gpio_request() returns the error without dropping it. gpiolib does not call ->free() when ->request() fails, so zynq_gpio_free(), which holds the only matching pm_runtime_put(), never runs. The reference is leaked and the controller can no longer runtime-suspend, so its clock stays enabled. Switch to pm_runtime_resume_and_get(), which only increments the usage counter on success. Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller") Cc: stable@vger.kernel.org Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260922092102.1053513-1-khurana.ridham222@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 40c010c1866382cb63ba7497d6ec74fcc60ab9cf Author: Wentao Liang Date: Wed Sep 16 09:47:01 2026 +0000 gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out() commit e9d810279f84b30738f7790c0ed15f8dd5b9024a upstream. Switching a persistent GPIO line from input to output acquires a runtime PM reference on the parent device, but if the subsequent regmap_update_bits() fails the reference is never dropped and no later direction_in() can balance it since the direction was never changed. Drop the reference on the update failure path. Fixes: 27a49ed17e22 ("gpio: arizona: Add support for GPIOs that need to be maintained") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260916094701.2007509-1-vulab@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 050a0aa3c80907b8c60a396b7e04d48d8b1a9e70 Author: Hui Peng Date: Mon Sep 21 04:40:25 2026 +0000 ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST commit 2d959c75c27f90e9ec489d18ce5ee6b852ad4741 upstream. In seg6_genl_policy, SEG6_ATTR_DST is defined with .type = NLA_BINARY and .len = sizeof(struct in6_addr). For NLA_BINARY, .len only enforces the maximum payload length and permits shorter payloads (e.g., 0 bytes). When seg6_genl_set_tunsrc() copies sizeof(struct in6_addr) bytes via kmemdup(val, sizeof(*val), GFP_KERNEL), a short SEG6_ATTR_DST attribute triggers a 16-byte out-of-bounds read past skb->tail into uninitialized skb->head memory, which is stored in sdata->tun_src and leaked back to userspace via SEG6_CMD_GET_TUNSRC. Switch SEG6_ATTR_DST in seg6_genl_policy to NLA_POLICY_EXACT_LEN(sizeof(struct in6_addr)) so that generic netlink validation rejects any attribute whose length is not exactly sizeof(struct in6_addr) with -ERANGE. Tested in QEMU against Linux 7.3.0-rc3 by sending a SEG6_CMD_SET_TUNSRC Generic Netlink message with a 0-byte SEG6_ATTR_DST attribute followed by SEG6_CMD_GET_TUNSRC. On the unfixed kernel, SEG6_CMD_SET_TUNSRC succeeds (err = 0) and SEG6_CMD_GET_TUNSRC leaks 16 bytes of uninitialized kernel heap memory (tun_src = 836a61ecc4d25a1042a8d60411cfb378); with this patch applied, SEG6_CMD_SET_TUNSRC is rejected by netlink policy validation with -ERANGE (-34) and tun_src remains zeroed. Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6") Cc: stable@vger.kernel.org Signed-off-by: Hui Peng Reviewed-by: Hangbin Liu Reviewed-by: Justin Iurman Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260921044025.1535982-1-benquike@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ca96b38730e31357ef4a9d76af1336958ac670d7 Author: Norbert Szetei Date: Wed Sep 16 21:57:53 2026 +0200 ipv6: do not let ipv6_find_hdr() return an offset past the packet end commit ee319bd3a0e976af5087cbe59ebc50a66f31d202 upstream. ipv6_find_hdr() walks the extension header chain, skipping each header by the length that header itself declares. ipv6_optlen() returns up to 2048, and the skip is never checked against skb->len, so the offset stored in *offset can point past the end of the packet. openvswitch installs that offset as the transport header, and update_ipv6_checksum() then reads and writes the transport checksum field out of bounds: BUG: KASAN: slab-use-after-free in inet_proto_csum_replace16+0x445/0x470 Read of size 2 at addr ffff88810b754b06 by task ovs_ipv6_oob/629 CPU: 4 UID: 1000 PID: 629 Comm: ovs_ipv6_oob Tainted: G N 7.3.0-rc3+ #348 Call Trace: inet_proto_csum_replace16+0x445/0x470 set_ipv6_addr+0x3dd/0x460 do_execute_actions+0x6a3d/0x7c40 ovs_execute_actions+0xfd/0x480 ovs_packet_cmd_execute+0xc38/0xf20 genl_rcv_msg+0x59e/0x870 netlink_rcv_skb+0x18b/0x450 genl_rcv+0x2d/0x40 netlink_unicast+0x6bc/0xa20 The buggy address belongs to the object at ffff88810b754980 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 390 bytes inside of freed 704-byte region [ffff88810b754980, ffff88810b754c40) Other callers use that offset too, so bound it here rather than in one caller. Reject a header whose declared length does not fit in the packet. ipv6_find_hdr() already fails with -EBADMSG on a malformed chain, so this adds no new failure mode. Fixes: f8f626754ebe ("ipv6: Move ipv6_find_hdr() out of Netfilter code.") Suggested-by: Ilya Maximets Suggested-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Ido Schimmel Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/8F80BA1A-DDFD-432D-9075-242A3435FEB5@doyensec.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 874fd58b321a9238e47c2a46345444287f2a5781 Author: Wentao Liang Date: Thu Sep 17 11:01:35 2026 +0000 fsl/fman: Fix clk reference leak in read_dts_node() commit a644f09b2090ad22a13fbcf9d141084f573108ef upstream. of_clk_get() returns a clock with its reference count incremented, but read_dts_node() only uses it to read the rate and never calls clk_put(). The clock is not stored anywhere, so the reference cannot be released later either. Release the clock once its rate has been read, which also covers the error path taken when the rate is zero. Fixes: 414fd46e7762 ("fsl/fman: Add FMan support") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260917110135.2148068-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8ffececcb88262389b4f91fed0fe4884b68204bc Author: Pavankumar Kondeti Date: Fri Sep 25 15:25:12 2026 +0530 workqueue: Fix NULL current_pwq deref in flush dependency check commit db6365ced4d5855e321f772b240c0e473bcfcdd5 upstream. check_flush_dependency() uses current_wq_worker() to determine whether the caller is a workqueue worker and then dereferences worker->current_pwq to test whether the current workqueue is WQ_MEM_RECLAIM. current_wq_worker() only means that %current has PF_WQ_WORKER set. A kworker can reach check_flush_dependency() while it is not executing a work item. One such path is worker_thread() acting as the pool manager, where create_worker() does GFP_KERNEL allocation and the allocation path invokes the OOM notifier. In that state worker->current_pwq is NULL because current_pwq is set only by process_one_work() and cleared again after the work function returns. [ 416.760634][ T375] Call trace: [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P) [ 416.760648][ T375] __flush_work+0x98/0x224 [ 416.760657][ T375] flush_work+0x30/0x44 [ 416.760665][ T375] ... [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0 [ 416.760719][ T375] out_of_memory+0xb4/0x458 [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8 [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4 [ 416.760753][ T375] new_slab+0x12c/0x484 [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c [ 416.760765][ T375] __slab_alloc+0x74/0xd8 [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304 [ 416.760779][ T375] alloc_worker+0x28/0x60 [ 416.760785][ T375] create_worker+0x4c/0x20c [ 416.760790][ T375] worker_thread+0xe8/0x2b8 [ 416.760796][ T375] kthread+0x1a8/0x200 [ 416.760805][ T375] ret_from_fork+0x10/0x20 Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the kworker is not currently executing a work item, there is no current workqueue to diagnose with that warning. The PF_MEMALLOC warning is left unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target is still reported. Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Pavankumar Kondeti Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit fd20220f86947d66d4dba2d76f13a28dbd86ef30 Author: Hui Peng Date: Mon Sep 21 04:59:20 2026 +0000 fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT commit d22609f3d13fc5baacd92c222731b03c593401db upstream. Commit 7a9bc9e3f423 ("fou: Don't allow 0 for FOU_ATTR_IPPROTO.") added NLA_POLICY_MIN(NLA_U8, 1) to fou_nl_policy[FOU_ATTR_IPPROTO], which rejects an explicitly supplied FOU_ATTR_IPPROTO == 0 attribute with -ERANGE. However, FOU_ATTR_IPPROTO is an optional netlink attribute. When a user sends FOU_CMD_ADD with FOU_ATTR_TYPE set to FOU_ENCAP_DIRECT and omits FOU_ATTR_IPPROTO entirely, nla_policy validation succeeds and parse_nl_config() leaves cfg->protocol as 0 (from memset(cfg, 0, sizeof(*cfg))). fou_create() then creates a FOU_ENCAP_DIRECT socket with fou->protocol == 0. In fou_udp_recv(), returning -fou->protocol to udp_queue_rcv_one_skb() triggers IP protocol resubmission when fou->protocol > 0, whereas returning 0 tells the UDP tunnel layer that the skb was consumed without freeing it. When fou->protocol == 0, every packet received on the socket returns 0 from fou_udp_recv() and leaks the sk_buff. Reject FOU_ENCAP_DIRECT when !cfg->protocol in fou_create() so that creating a direct encapsulation port without FOU_ATTR_IPPROTO fails with -EINVAL while leaving FOU_CMD_DEL and FOU_CMD_GET (which share parse_nl_config()) unaffected. Tested in QEMU against Linux 7.3.0-rc3 by sending a FOU_CMD_ADD Generic Netlink request with FOU_ATTR_PORT = 5555 and FOU_ATTR_TYPE = FOU_ENCAP_DIRECT while omitting FOU_ATTR_IPPROTO. On the unfixed kernel, FOU_CMD_ADD succeeds (err = 0), FOU_CMD_GET reports fou->type = 1 and fou->protocol = 0, and sending 4000 UDP packets to 127.0.0.1:5555 leaks all 4000 sk_buffs (SUnreclaim in /proc/meminfo grows from 41456 kB to 59008 kB, +17552 kB); with this patch applied, FOU_CMD_ADD is rejected with -EINVAL (-22). Fixes: 23461551c006 ("fou: Support for foo-over-udp RX path") Fixes: 7a9bc9e3f423 ("fou: Don't allow 0 for FOU_ATTR_IPPROTO.") Cc: stable@vger.kernel.org Signed-off-by: Hui Peng Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260921045920.1613098-1-benquike@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 02afd75649a4e001031ed82153a5c39312ec0737 Author: Dairui Zhang Date: Wed Sep 23 13:01:01 2026 +0800 af_packet: fix integer overflow in prb_calc_retire_blk_tmo() commit 56d82862a0a243ac14ba11b6d7b57ddc2d064b95 upstream. prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic: mbits = (blk_size_in_bytes * 8) / (1024 * 1024); If I'm reading the validation right, tp_block_size is user controlled and packet_set_ring() only rejects values that are <= 0 as int or not page aligned, so a 256MiB block goes right through (and alloc_one_pg_vec_page() even has a vzalloc fallback for it). 0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps (div == 1) the function ends up returning -2047. The condition is actually (8 * size) mod 2^32 >= 2^31 && div == 1, so the trigger set is [256,512), [768,1024), [1280,1536) and [1792,2048) MiB. Other sizes wrap to non-negative values and faster links divide the unsigned value back below 2^31, which is why this doesn't blow up for everyone. What makes it fatal is what happens next in init_prb_bdqc(): p1->interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...)); hrtimer_start(&p1->retire_blk_timer, p1->interval_ktime, HRTIMER_MODE_REL_SOFT); A negative relative timeout expires immediately. The callback unconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns the negative interval into hrtimer_resolution: if (interval < hrtimer_resolution) interval = hrtimer_resolution; So the SOFT timer re-fires at the maximum rate forever, holding sk_receive_queue.lock each pass. One CPU spins in softirq until the socket is closed. Repeat with more rings and the machine is gone. The overflow itself is ancient - it was introduced together with TPACKET_V3 in f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation."). Its effect prior to f7460d2989fa ("net: af_packet: Use hrtimer to do the retire operation", v6.18) was not as clear-cut, though: the return value was stored into an unsigned short retire_blk_tov, so a negative result was truncated, and a 0-jiffy delay loop could be programmed as well. Neither is nearly as detrimental as the immediate maximum-rate spin the hrtimer conversion turned it into. (Unrelated to CVE-2019-20812 - that one was the ethtool failure path returning 0, which now returns DEFAULT_PRB_RETIRE_TOV.) Reproducer, needs CAP_NET_RAW (a --network host container has it by default) and a 1 Gbps NIC (QEMU e1000 works): int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); bind(fd, ...); int v = TPACKET_V3; setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v)); struct tpacket_req3 req = { .tp_block_size = 0x10000000, .tp_block_nr = 1, .tp_frame_size = 2048, .tp_frame_nr = 0x10000000 / 2048, .tp_retire_blk_tov = 0, }; setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req)); Compute in 64 bits instead. The operands are already bounded by the existing validation, so nothing else changes. If you'd prefer a different fix, just say so and I'll respin. Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Cc: stable@vger.kernel.org Signed-off-by: Dairui Zhang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260923050101.1510064-1-zhangdairui@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c0af3fd150fdc43821df3bb77e5ec74faf4dfc7a Author: Aohan Mei Date: Mon Sep 21 17:37:04 2026 +0800 sctp: discard the rest of the packet on a stale-cookie error commit 4498467a8af06cfa3d71cb04bd7c4170dec8f449 upstream. When an association is in COOKIE-ECHOED state and the peer sends a bundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primary addresses, processing the ERROR chunk takes the non-fatal stale-cookie retry path sctp_sf_do_5_2_6_stale(), which queues SCTP_CMD_DEL_NON_PRIMARY while keeping the association alive. sctp_cmd_del_non_primary() removes every non-primary transport - including the very transport this packet arrived on, which is still referenced by the receive lookup and shared by all chunks of the packet via chunk->transport. sctp_assoc_rm_peer() does redirect asoc->peer.last_data_from away from the removed transport, but right afterwards the bundled DATA chunk makes sctp_assoc_bh_rcv() re-register asoc->peer.last_data_from = chunk->transport unconditionally, undoing the redirection with the just-removed transport. Once the packet is done, the receive reference is dropped and the transport is RCU-freed, while the surviving association keeps the dangling last_data_from. A later FWD-TSN (or the delayed SACK timer) makes sctp_gen_sack() dereference it (->param_flags and friends), and sctp_make_sack()/sctp_outq_select_transport() may write to the freed object and link it into the live transport list. This is a use-after-free triggerable by any malicious SCTP peer (or a local unprivileged user acting as one) with no capabilities required: BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660 Read of size 4 at addr ffff88800e1e356c by task poc/115 Call Trace: sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <- sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv Allocated: sctp_transport_new <- sctp_assoc_add_peer <- sctp_process_init (INIT-ACK processing) Freed: kfree <- sctp_transport_destroy_rcu <- rcu_core (call_rcu queued by sctp_transport_put at end of sctp_rcv) The buggy address is located 364 bytes inside of freed 1024-byte region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k Note that commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") only covers the window between the receive lookup and the chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog); here the transport is removed *while* the packet is being processed, by an earlier chunk of the same packet, so the drop in sctp_inq_push() does not reach this path. Verified with the bundled [ERROR(Stale Cookie)][DATA] + FWD-TSN reproducer: the KASAN report above still fires with that commit applied, and is gone with this patch on top. Fix it by discarding the rest of the packet on this path, as suggested by Xin. After the stale-cookie ERROR has sent the association back to COOKIE-WAIT and removed the non-primary transports, the remaining chunks of the packet can only run against the restarted handshake while referencing the removed arrival transport through chunk->transport: besides the last_data_from registration above, sctp_cmd_setup_t2() and the sctp_make_*() reply builders would also copy that pointer into association-lifetime state that sctp_assoc_rm_peer() has already sanitized. Let the peer retransmit them, in line with what sctp_inq_push() does for chunks whose transport was removed before processing. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Xin Long Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Signed-off-by: Aohan Mei Acked-by: Xin Long Link: https://patch.msgid.link/20260921093707.1432184-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit edc6593c442278fceff0120e8cc58bc592168c35 Author: Eric Dumazet Date: Sun Sep 13 04:42:33 2026 +0000 tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow commit 99cc2a62e07a44a22254d7beca9ef1f8ad886d0d upstream. Commit 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") rejected duplicate/stale ACKs in tipc_group_proto_rcv() by returning early when less_eq(acked, m->bc_acked). However, that check remains incomplete in two ways: 1. When grp->bc_ackers is zero (e.g. on a quiet group, when replicast ACKs were not requested, or after all expected members have already acknowledged), an unexpected GRP_ACK_MSG with acked > m->bc_acked passes less_eq() and unconditionally decrements grp->bc_ackers. Because bc_ackers is a u16, this wraps to 65535, causing tipc_group_bc_cong() to permanently report congestion and blocking all future group broadcasts on the socket. 2. During an active broadcast round (grp->bc_ackers > 0), the sender transmits packet S and advances grp->bc_snd_nxt to S + 1. Receivers increment their expected counter to S + 1 upon consuming packet S, so the only valid ACK value for the current round is strictly acked == grp->bc_snd_nxt. However, tipc_group_update_bc_members() initializes each member's m->bc_acked to prev = grp->bc_snd_nxt - 1 (S - 1 before increment). This leaves a 2-sequence gap (S - 1 to S + 1) in sequence space. An incoming ACK is therefore neither rejected as duplicate nor prevented from decrementing grp->bc_ackers if an unexpected or stale value (such as S) is received. A member sending acked = S followed by acked = S + 1 could decrement grp->bc_ackers twice in the same round, prematurely clearing bc_ackers or underflowing it. Fix this by: - Dropping GRP_ACK_MSG immediately if grp->bc_ackers is zero. - Requiring acked == grp->bc_snd_nxt and rejecting duplicates where m->bc_acked == acked. Because replicast broadcast rounds are strictly sequential, only grp->bc_snd_nxt can be acknowledged, and each member can acknowledge at most once per round. Note that a related pre-existing issue in tipc_group_delete_member() (where grp->bc_ackers decrementing to zero upon member departure does not restore *grp->open or trigger a socket wakeup) will be addressed in a separate patch. Fixes: 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") Fixes: 2f487712b893 ("tipc: guarantee that group broadcast doesn't bypass group unicast") Reported-by: James Burton Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260913044233.193927-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5002b68ad1861c260e8cb333318f109de66691e4 Author: Mario Limonciello Date: Tue Sep 8 14:05:59 2026 -0500 x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11 commit 4fde448225123442c5796f54b7a4400e2d3cbaf6 upstream. Multiple users report data corruption during 64-bit DMA transfers on systems with AMD NBIO 7.7 and 7.11 controllers. This occurs when BIOS enables AMD "enhanced atomic operations" on PCIe Root Ports. When enhanced atomics are enabled, any 64-bit DMA access may be corrupted. Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models. Reported-by: Mikael Etienne Closes: https://lore.kernel.org/178789300872.392066.15963676631650361573@gmail.com/ Reported-by: Arthur Husband Closes: https://lore.kernel.org/20260406222335.379935-1-artmoty@gmail.com/ Reported-by: Alvin Lim Closes: https://lore.kernel.org/20260621100844.1224301-1-alvinwylim@gmail.com/ Signed-off-by: Mario Limonciello [bhelgaas: commit log, s/IOVA/DMA/ in comment] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Cc: David Laight Cc: John Smith Cc: Lennert Buytenhek Cc: Niklas Cassel Cc: Roland Waltersson Link: https://patch.msgid.link/20260908190600.226485-2-mario.limonciello@amd.com Signed-off-by: Greg Kroah-Hartman commit 91c118727432a5d776d5fe86e0cf8eb1289ac1fc Author: Eric Dumazet Date: Mon Sep 28 10:08:32 2026 +0200 net: preserve skb_end_offset() in skb_unclone_keeptruesize() commit 2b88cba55883eaafbc9b7cbff0b2c7cdba71ed01 upstream. syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len) in skb_try_coalesce() [1] I was able to root cause the issue to kfence. When kfence is in action, the following assertion is no longer true: int size = xxxx; void *ptr1 = kmalloc(size, gfp); void *ptr2 = kmalloc(size, gfp); if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2)); We attempted to fix these issues in the blamed commits, but forgot that TCP was possibly shifting data after skb_unclone_keeptruesize() has been used, notably from tcp_retrans_try_collapse(). So we not only need to keep same skb->truesize value, we also need to make sure TCP wont fill new tailroom that pskb_expand_head() was able to get from a addr = kmalloc(...) followed by ksize(addr) Split skb_unclone_keeptruesize() into two parts: 1) Inline skb_unclone_keeptruesize() for the common case, when skb is not cloned. 2) Out of line __skb_unclone_keeptruesize() for the 'slow path'. WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Modules linked in: CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa RSP: 0018:ffffc900063af268 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000 RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003 RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000 R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8 R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155 FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: c4777efa751d ("net: add and use skb_unclone_keeptruesize() helper") Fixes: 097b9146c0e2 ("net: fix up truesize of cloned skb in skb_prepare_for_shift()") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Marco Elver Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit 42621bedf2bf3b28f59003ea4623e3621bb6ed23 Author: Eric Dumazet Date: Mon Sep 28 10:08:31 2026 +0200 net: add skb_set_end_offset() helper commit 763087dab97547230a6807c865a6a5ae53a59247 upstream. We have multiple places where this helper is convenient, and plan using it in the following patch. Signed-off-by: Eric Dumazet Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit 35ca1748ebf8d3a1025d55c85f4b96add952ed20 Author: Eric Dumazet Date: Mon Sep 28 10:08:30 2026 +0200 net: add and use skb_unclone_keeptruesize() helper commit c4777efa751d293e369aec464ce6875e957be255 upstream. While commit 097b9146c0e2 ("net: fix up truesize of cloned skb in skb_prepare_for_shift()") fixed immediate issues found when KFENCE was enabled/tested, there are still similar issues, when tcp_trim_head() hits KFENCE while the master skb is cloned. This happens under heavy networking TX workloads, when the TX completion might be delayed after incoming ACK. This patch fixes the WARNING in sk_stream_kill_queues when sk->sk_mem_queued/sk->sk_forward_alloc are not zero. Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB") Signed-off-by: Eric Dumazet Acked-by: Marco Elver Link: https://lore.kernel.org/r/20211102004555.1359210-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit ed8d3bd8272e49ea987100de2abfb13710329a9b Author: Pablo Neira Ayuso Date: Mon Sep 28 10:10:13 2026 +0200 netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase [ Upstream commit a6134e62dba2ea4f760b29d5226907f447c92400 ] Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on. 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: Sasha Levin Signed-off-by: Benjamin Robin (Schneider Electric) Signed-off-by: Sasha Levin commit df75396f6a62fd55d612aa061ce13556dfc787c1 Author: Pablo Neira Ayuso Date: Mon Sep 28 10:10:12 2026 +0200 rculist: add list_splice_rcu() for private lists [ Upstream commit f902877b635551513729bdf9a8d1422c4aab7741 ] This patch adds a helper function, list_splice_rcu(), to safely splice a private (non-RCU-protected) list into an RCU-protected list. The function ensures that only the pointer visible to RCU readers (prev->next) is updated using rcu_assign_pointer(), while the rest of the list manipulations are performed with regular assignments, as the source list is private and not visible to concurrent RCU readers. This is useful for moving elements from a private list into a global RCU-protected list, ensuring safe publication for RCU readers. Subsystems with some sort of batching mechanism from userspace can benefit from this new function. The function __list_splice_rcu() has been added for clarity and to follow the same pattern as in the existing list_splice*() interfaces, where there is a check to ensure that the list to splice is not empty. Note that __list_splice_rcu() has no documentation for this reason. Reviewed-by: Paul E. McKenney Signed-off-by: Pablo Neira Ayuso Signed-off-by: Benjamin Robin (Schneider Electric) Signed-off-by: Sasha Levin commit 3684e2273ba94553af3c5195a46a50214a1a96e3 Author: Hui Peng Date: Sat Sep 19 20:48:08 2026 +0000 autofs: fix sbi->pipe file reference leak in autofs_kill_sb() [ Upstream commit aa5e44b29ffe4eaa08cc2237fd65bc2596bc023e ] When autofs_fill_super() fails before clearing AUTOFS_SBI_CATATONIC (for example, when find_get_pid() fails on an invalid pgrp mount option, or when an fs_context is closed before mounting), deactivate_locked_super() invokes autofs_kill_sb() -> autofs_catatonic_mode(sbi). Because AUTOFS_SBI_CATATONIC is still set in sbi->flags, autofs_catatonic_mode() returns early without calling fput(sbi->pipe), permanently leaking the pipe struct file reference. Explicitly release sbi->pipe in autofs_kill_sb() if it is still non-NULL after autofs_catatonic_mode(). Fixes: ebc921ca9b92 ("autofs: copy autofs4 to autofs") Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919204808.2812930-1-benquike@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 55e007fc3b4d76fa4d6b4660f6904fe6ab045a1b Author: Eric Dumazet Date: Thu Sep 24 08:29:51 2026 +0000 vlan: ensure sufficient headroom in vlan_dev_hard_header() [ Upstream commit cd5dd68267c4238795fadaf02b3575ca3f8a6500 ] Callers that only reserve ETH_HLEN or less (such as llc_alloc_frame()), or skbs allocated before dynamic device/headroom changes (e.g. toggling VLAN_FLAG_REORDER_HDR or bonding/team switching slaves), can reach vlan_dev_hard_header() with insufficient headroom and trigger skb_under_panic(). Use skb_cow_head() in vlan_dev_hard_header() when VLAN_FLAG_REORDER_HDR is not set to ensure sufficient headroom for the VLAN header(s) and the underlying device hard header. Use READ_ONCE() to read dev->hard_header_len and dev->needed_headroom as they can be updated concurrently under RTNL (e.g. in vlan_transfer_features()) while vlan_dev_hard_header() runs locklessly on the transmit path. Also avoid LL_RESERVED_SPACE(dev) here so that the extra HH_DATA_MOD alignment padding does not trigger unnecessary pskb_expand_head() reallocations on inner stacked VLAN devices after the outer VLAN header has been pushed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Zixuan Chai Closes: https://lore.kernel.org/netdev/cover.1789987105.git.petalzu987@gmail.com/ Link: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Cc: Hangbin Liu Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260924082951.1599377-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b0f1c36903793feaa1d350f4e7a4cefddbba8d9b Author: Eric Dumazet Date: Thu Sep 24 08:29:50 2026 +0000 net/sched: sch_teql: fix shadowed err in __teql_resolve() [ Upstream commit 907b978e82cb4c1c245fc2985bb27c5d5c88c8f6 ] __teql_resolve() declares an inner 'int err;' inside the 'if (neigh_event_send(n, skb_res) == 0)' block, shadowing the outer 'int err = 0;'. As a result, a negative return from dev_hard_header() is written to the inner variable and __teql_resolve() still returns 0. Remove the shadowed variable and set the outer err to -EINVAL when dev_hard_header() returns a negative error. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Closes: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260924082951.1599377-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 490976c5cb3e1768323e235ada7a3edf1fb85f1c Author: Eric Dumazet Date: Thu Sep 24 08:29:49 2026 +0000 bridge: check llc_mac_hdr_init() return value in br_send_bpdu() [ Upstream commit ac704ff08e511c87643799c385f55ecd69b85e03 ] If llc_mac_hdr_init() fails (for instance if the port device type does not support LLC or dev_hard_header() fails), br_send_bpdu() should drop the skb instead of resetting the mac header to the LLC payload and transmitting a malformed frame. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Closes: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Cc: Nikolay Aleksandrov Cc: Ido Schimmel Cc: bridge@lists.linux.dev Signed-off-by: Eric Dumazet Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260924082951.1599377-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fec0fe6838a7f45175667701fb51abb23a6ffb1e Author: Eric Dumazet Date: Thu Sep 24 08:29:48 2026 +0000 llc: fix skb UAF and leaks on llc_mac_hdr_init() failure [ Upstream commit 72f9dd522f8d6c5a00be9695c7bb74631eb5069e ] In llc_conn_ac_resend_i_xxx_x_set_0_or_send_rr(), if llc_mac_hdr_init() fails, kfree_skb(skb) is called instead of kfree_skb(nskb). This leaks the newly allocated nskb, reads from the freed skb via LLC_I_GET_NR(pdu), and double-frees skb when llc_conn_state_process() drops its reference. In llc_sap_action_send_xid_r() and llc_sap_action_send_test_r(), nskb is leaked if llc_mac_hdr_init() returns an error. Free nskb in all three error paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Closes: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260924082951.1599377-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8fe0fd32e632649a1b06d4f6eecb76c78c2bd9c8 Author: Ginger Li Date: Tue Sep 22 16:09:09 2026 +0800 tipc: Fix a data race on mon->peer_cnt in mon_timeout() [ Upstream commit 8e1937fed6738460554ec123c64839e2445e7d53 ] mon_timeout() evaluates dom_size(mon->peer_cnt) before it takes mon->lock, while mon->peer_cnt is updated under that lock by tipc_mon_add_peer() and tipc_mon_remove_peer(). The value can therefore be stale, and the decision whether the local domain has to be recomputed can be based on an outdated member count. Read mon->peer_cnt inside the write_lock_bh(&mon->lock) protected region. Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework") Signed-off-by: Ginger Li Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260922080909.21123-1-ginger.jzllee@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 967e10f40a0c6732db299cbe001df0e859196055 Author: Norbert Szetei Date: Mon Sep 21 17:03:57 2026 +0200 net: xps: reject an out of range traffic class [ Upstream commit 4da3b7b8b50f3e2fde54a4c18a82a8e3f6223910 ] Only the entries below dev->num_tc are valid in dev->tc_to_txq[], and dev->prio_tc_map[] may only name classes below it. netdev_set_num_tc() lowers dev->num_tc without touching either array. netdev_txq_to_tc() walks all TC_MAX_QUEUE slots and netdev_get_prio_tc_map() returns the entry as it stands, so a leftover entry is handed out as a traffic class >= dev->num_tc. Taking that class from netdev_txq_to_tc(), __netif_set_xps_queue() rejects only a negative one and indexes an XPS map sized for dev->num_tc classes: tci = j * num_tc + tc; RCU_INIT_POINTER(new_dev_maps->attr_map[tci], map); attr_map[] holds nr_ids * num_tc entries and j runs over the ids named in the mask, so a class that is not below num_tc pushes tci past the end of the map for the last ids and the store overruns it. Any caller that lowers num_tc leaves such entries behind, and mqprio_destroy() tears down with netdev_set_num_tc(dev, 0) rather than netdev_reset_tc(). After mqprio with 8 classes then 1, tc_to_txq[1..7] still describe txq 1..7. The splat is from an XPS write to txq 2 on a veth with 8 rx queues: attr_map[] has 8 * 1 entries, tci = j + 2, and j == 6 stores one past the end of the 88-byte map: BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue (net/core/dev.c:2954) Write of size 8 at addr ffff88813016bc58 by task xps_oob/634 __netif_set_xps_queue (net/core/dev.c:2954) xps_rxqs_store (net/core/net-sysfs.c:1880) netdev_queue_attr_store (net/core/net-sysfs.c:1390) Allocated by task 634: __kmalloc_noprof (mm/slub.c:5439) __netif_set_xps_queue (net/core/dev.c:2937) The buggy address is located 0 bytes to the right of allocated 88-byte region [ffff88813016bc00, ffff88813016bc58) Reject a class the map has no room for. Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes") Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/162DD16F-54C6-444A-9E09-0B8CB3D591F2@doyensec.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c80315da84998b69b8829785a174b0bf72a81992 Author: Xuanqiang Luo Date: Mon Sep 21 11:18:59 2026 +0800 ip_gre: Reject enabling collect metadata through changelink [ Upstream commit a3f315be9d30eeb6938d11fa17fd4b32d52f7c42 ] ipgre_netlink_parms() can enable collect_md on an existing GRE, GRETAP or ERSPAN device. Unlike newlink, changelink does not enforce metadata tunnel uniqueness. Converting a non-metadata device can therefore replace the metadata receive entry for another device of the same type in the same netns. Deleting either device then clears the shared entry, breaking metadata receive lookup for the surviving device. If parameter validation fails after collect_md is set, deleting the modified device can also clear an entry it never owned. Reject enabling metadata mode in both changelink callbacks before any encapsulation or tunnel parameters are modified. Allow requests that repeat the metadata attribute on an existing metadata device. Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260921031859.9283-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c4e432132a97b82edf28fa172c39f743e6bfb26 Author: Shihuang Liu Date: Sat Sep 19 21:36:04 2026 +0800 net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6() [ Upstream commit 3b4e0b0c008a8c1b474730248cd5b873026c74bd ] skb_maybe_pull_tail() subtracts skb_headlen(skb) from the unsigned max argument and passes the result to __pskb_pull_tail() as a signed int. The function does not ensure that max is at least skb_headlen(skb). This can happen while parsing IPv6 extension headers when an skb already has a linear area larger than MAX_IPV6_HDR_LEN. Once the parser needs data beyond the linear area, max - skb_headlen(skb) wraps and is converted to a negative delta. __pskb_pull_tail() then passes that negative length to skb_copy_bits(), where it can become a very large copy length. Pass the requested length itself as the pull bound at the three extension-header call sites, so the delta can no longer go negative. Fixes: 1431fb31ecba ("xen-netback: fix fragment detection in checksum setup") Suggested-by: Eric Dumazet Signed-off-by: Shihuang Liu Link: https://patch.msgid.link/20260919133604.50948-1-shlomojune6@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c587ea1337b4849aec4220b98e5e8d5f5f9ce0c Author: Victor Nogueira Date: Sun Sep 20 14:07:01 2026 -0300 net/sched: act_gate: budget the per-entry list in get_fill_size [ Upstream commit cfa165cbfbed9d0f4bbc22fef4309f595a3ab187 ] tcf_gate_get_fill_size returns only the TCA_GATE_PARMS size, but tcf_gate_dump also emits three 64-bit timestamps, the clock id, flags, priority and the variable-length TCA_GATE_ENTRY_LIST nest. The per-entry nest is unbounded: parse_gate_list places no cap on the number of sched-entries, so a gate with many entries can push the real dump well past the skb that tca_get_fill allocates from this size. RTM_NEWACTION then fails the add-notify with -EINVAL while the action is already committed to the IDR, and a subsequent RTM_GETACTION on the installed gate also returns -EINVAL because its dump no longer fits. Fix this by accounting for the missing fields in tcf_gate_get_fill_size along with all elements in the entries list. Note that sizing the reply from the action lets an oversized gate install cleanly for the first time: with the input unbounded by parse_gate_list, the sized skb can now grow well above NLMSG_GOODSIZE per netlink request (a transient GFP_KERNEL allocation reachable only with namespace-local CAP_NET_ADMIN). Overload from a malicious netns admin is hardening material, not net, per the discussion at https://lore.kernel.org/netdev/20260914191108.55a1a4f1@kernel.org/; a follow-up patch for net-next will cap the sched-entry count. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824153903.4143642-1-victor@mojatatu.com Tested-by: hybris Co-developed-by: Jamal Hadi Salim Signed-off-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/QDISC-3BLH.v1.20260914203033@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8db3b1e012a8b25078dfa1efabe3d0cd2916dcba Author: Deepanshu Kartikey Date: Wed Sep 23 09:26:27 2026 +0530 nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid() [ Upstream commit b61732f47316d45f27706db7812950145d3327b5 ] frame->ccid.datalen is read directly from the USB response frame and used, unchecked, as an index into frame->data[]. A malicious or malfunctioning device can set this field to an arbitrary value, causing the driver to read far outside the received buffer. Bound ccid.datalen against the maximum possible ACR122 frame size before using it. This replaces the existing datalen == 0 check, since datalen < 2 already covers that case and additionally rejects datalen == 1, which would still underflow the "datalen - 2" offset used below. Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation") Reported-by: syzbot+1853daab1a47603d4678@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1853daab1a47603d4678 Tested-by: syzbot+1853daab1a47603d4678@syzkaller.appspotmail.com Assisted-by: LLM Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260923035627.6210-1-kartikey406@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 75f7c5a42fa1483f5912279a749417c284ad708f Author: Ömer Mete Kaya Date: Tue Sep 8 19:18:01 2026 +0300 nfc: llcp: fix slab-out-of-bounds reads when logging service names [ Upstream commit 7dcf371a35632f035baf77bcf2c129165f772ce4 ] nfc_llcp_wks_sap() and nfc_llcp_build_sdreq_tlv() pass non-null- terminated strings to pr_debug() using the %s format specifier. The buffers are allocated via kmemdup() or come from netlink attributes and are not guaranteed to be null-terminated, causing __dynamic_pr_debug() to read beyond the allocated region: KASAN: slab-out-of-bounds Read in __dynamic_pr_debug Fix both call sites by using %.*s with the explicit length to limit the output to the actual length of the string. Fixes: d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface") Reported-by: syzbot+1e3df0852e82c21ca418@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1e3df0852e82c21ca418 Signed-off-by: Ömer Mete Kaya Link: https://patch.msgid.link/20260908161952.731468-1-omermetekaya0@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 0c83a8a45fed256ccc5fe7160b436b671fc79fb8 Author: Ömer Mete Kaya Date: Wed Sep 9 15:14:31 2026 +0300 nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap() [ Upstream commit 408cff6bd60636df201274d320edfdfde9ed41db ] nfc_llcp_wks_sap() compares only service_name_len bytes, so a short service_name like "u" matches longer WKS strings like "urn:nfc:sn:snep". Fix by requiring exact length match before strncmp(). Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: Ömer Mete Kaya Link: https://patch.msgid.link/20260909121437.33744-1-omermetekaya0@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 27b0a3e414f01d47d9437f1c135a0992d9600313 Author: Ömer Mete Kaya Date: Wed Sep 9 15:16:22 2026 +0300 nfc: llcp: fix -ENOMEM on connect with zero-length service name [ Upstream commit c04981e42d94f39c1dba965cc462a046e946a6c5 ] When service_name_len is 0, kmemdup() returns ZERO_SIZE_PTR which passes the NULL check, causing nfc_llcp_send_connect() to attempt building a zero-length service name TLV and fail with -ENOMEM. Fix by setting service_name to NULL directly when service_name_len is 0. Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: Ömer Mete Kaya Link: https://patch.msgid.link/20260909122029.34081-1-omermetekaya0@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit e47b2a350bb0ff123434ec5484c6dc3333b0727c Author: Pengpeng Hou Date: Sun Aug 30 21:29:58 2026 +0800 nfc: st21nfca: validate ISO15693 inventory length [ Upstream commit 7f2ea5ed588c03d481f0301e6c3d4240132383fb ] The ISO15693 inventory helper removes a two-byte prefix without checking that it exists, then accepts a one-byte remainder before reading data[1] as the DSFID. Require the prefix and at least two remaining bytes before copying the UID data and reading the DSFID. Fixes: 7974728094d3 ("NFC: st21nfca: Add ISO15693 Reader/Writer support") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830132958.6397-1-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 5b1eca82085134bd92cd3810b0ef003c91e3f668 Author: Cong Nguyen Date: Mon Sep 14 19:11:29 2026 +0700 nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure [ Upstream commit 66f4300206b82b0b143ef0d9be90cd8d29f23a47 ] nfc_genl_llc_sdreq() builds a list of TLV nodes while walking nested netlink attrs, but 3 error paths (nested-attr parse failure, TLV alloc ENOMEM, nfc_llcp_send_snl_sdreq() failure) all skip freeing what was already queued. Route them through a new free_list label, mirroring the SDRES path in the same file which already does this. Harmless on the success path too -- send_snl_sdreq() drains the list as it moves nodes, so it's already empty by the time free_list runs. Fixes: d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface") Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260914121129.2098606-1-congnt264@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 54adcabb0f1deef1bdae5fc64779ed6d442721c9 Author: Lee Jones Date: Wed Sep 2 12:30:31 2026 +0000 nfc: llcp: Fix race condition in accept_queue lifecycle [ Upstream commit c3eef2f988a3db9690369d7cef9a3344dd9788d3 ] In nfc_llcp_socket_release(), sockets and listener accept queues are walked under the local sockets rwlock and bh_lock_sock(). However, bh_lock_sock() does not synchronise against process-context lock_sock() held by nfc_llcp_accept_dequeue() during accept(). Because socket_release() does not check sock_owned_by_user(), both paths can concurrently unlink and release the same child socket, resulting in use-after-free or a NULL pointer dereference of child->parent in nfc_llcp_accept_unlink(). Fix this synchronisation race by having nfc_llcp_socket_release() use process-context lock_sock() instead of bh_lock_sock(): 1. Pop sockets from the local sockets list under the write lock using nfc_llcp_sock_list_pop() so lock_sock() can be acquired without holding the rwlock. 2. Because lock_sock() can sleep, defer the final release of the nfc_llcp_local structure to a workqueue (release_work). This avoids a sleeping-in-atomic bug when the last local reference is dropped from softirq context. Additionally, hold a single device reference on local from registration until final destruction. 3. In nfc_llcp_local_get(), use kref_get_unless_zero() to prevent resurrecting a local object whose teardown has been scheduled. 4. In llcp_sock_accept(), verify that the listener socket state is still LLCP_LISTEN after waking from schedule_timeout() to prevent hangs if the listener is closed concurrently. 5. When unlinking unaccepted child sockets during listener release, unlink them from local->sockets, call sock_orphan(), and drop their initial sk_alloc creation reference via sock_put(). 6. Make nfc_llcp_accept_unlink() idempotent by guarding parent access with a NULL check. Fixes: 50b78b2a6500 ("NFC: Fix sleeping in atomic when releasing socket") Signed-off-by: Lee Jones Link: https://patch.msgid.link/20260902123033.1169067-1-lee@kernel.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit dd2d24add86b3b63cd87cf2feff98ae119ba19a6 Author: Aldo Ariel Panzardo Date: Thu Jul 16 20:26:57 2026 -0300 nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm() [ Upstream commit bf1460acdf8cf5a07c819f59785d40f20d113099 ] nfc_llcp_recv_dm() handles DM(NOBOUND)/DM(REJ) for a socket that is still linked on local->connecting_sockets: it looks the socket up with nfc_llcp_connecting_sock_get(), sets sk->sk_state = LLCP_CLOSED and returns, without taking the socket lock and without unlinking the socket from the connecting_sockets list. llcp_sock_release() selects the list to unlink from by sk_state: a socket in LLCP_CONNECTING is unlinked from connecting_sockets, otherwise from the sockets list. Because recv_dm left the socket physically on connecting_sockets but in the LLCP_CLOSED state, release() takes the else branch and calls nfc_llcp_sock_unlink(&local->sockets, sk). That runs sk_del_node_init() while holding sockets.lock, i.e. it removes the socket from the connecting_sockets hlist under the wrong lock. A concurrent connect() linking another socket onto connecting_sockets under connecting_sockets.lock then mutates the same hlist unserialized, which corrupts the list and desyncs the sk_add_node()/sk_del_node_init() sock_hold()/__sock_put() pairing. An unprivileged local process holding LLCP sockets, with the DM supplied by the remote peer over an established LLCP link, can drive this to leak kernel sockets without bound (the mis-decrement goes through the non-freeing __sock_put() path, so the object is never released), leading to memory exhaustion / DoS. This is the same class of bug that was fixed in the sibling handler nfc_llcp_recv_cc() by commit b493ea2765cc ("nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()"); recv_dm did not receive the equivalent fix. Fix it the same way: take lock_sock(), re-check that the socket is still hashed (release() may have won the race), and for the NOBOUND/REJ case unlink it from connecting_sockets before moving it to LLCP_CLOSED. The unlink drops the connecting_sockets membership reference via sk_del_node_init(), leaving the socket unhashed, so the later nfc_llcp_sock_unlink() in llcp_sock_release() becomes a no-op and no double put occurs. Fixes: a69f32af86e3 ("NFC: Socket linked list") Signed-off-by: Aldo Ariel Panzardo Link: https://patch.msgid.link/20260716232657.203145-1-qwe.aldo@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 8934d2889ae16a7c77520e002398d0689c1ecea5 Author: Pengpeng Hou Date: Wed Jul 15 16:44:05 2026 +0800 nfc: st21nfca: validate received frame size [ Upstream commit a653c01ce447f10c36b901646888c0330363af4f ] st21nfca_hci_i2c_repack() trims a received frame at its EOF marker before removing byte stuffing. It then assumes the truncated frame contains the LLC header and two CRC bytes, and it unconditionally reads the byte after an escape marker. A malformed frame can place EOF immediately after the start marker or can end its data portion with an escape marker. The former leaves too few bytes for check_crc(), while the latter makes the unstuffing loop read past the current skb length. Require the minimum framing bytes both before and after unstuffing. Use separate input and output cursors while removing byte stuffing, and reject an escape marker without its encoded byte. This keeps malformed frames within the received frame boundary before CRC processing. Fixes: 3096e25a3e40 ("NFC: st21nfca: Fix incorrect byte stuffing revocation") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715084405.41546-1-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 8a4555aad0dc405657618421b44c113486680e0c Author: Colin Ian King Date: Thu Dec 30 16:12:30 2021 +0000 nfc: st21nfca: remove redundant assignment to variable i [ Upstream commit 314fbde95769e0cff68ef74ccc261935bb0c6852 ] Variable i is being assigned a value that is never read, the assignment is redundant and can be removed. Cleans up clang-scan build warning: drivers/nfc/st21nfca/i2c.c:319:4: warning: Value stored to 'i' is never read [deadcode.DeadStores] i = 0; Signed-off-by: Colin Ian King Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211230161230.428457-1-colin.i.king@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: a653c01ce447 ("nfc: st21nfca: validate received frame size") Signed-off-by: Sasha Levin commit 842c0603cfa49530ef081f181a2ddbba77a37231 Author: Pengpeng Hou Date: Wed Jul 15 16:43:25 2026 +0800 nfc: nfcmrvl: validate helper command length before pull [ Upstream commit 686f942332b1667f13f3b8d6a2f50bcfbf42e277 ] The firmware download receive path removes the NCI data header and reads the helper command before validating the remaining packet length. A short frame can therefore reach the data access before the malformed packet is rejected. Validate the complete helper command length before stripping the NCI data header. Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715084325.40276-1-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit c2e69cc428f79a7e323919445e8b6484ddc3318d Author: Maxime Chevallier Date: Thu Sep 17 23:53:36 2026 +0200 net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K [ Upstream commit b42e7012773a0e81e97a2dda6ef907f5147a6658 ] DMA bufsize selection isn't made on the MTU but the actual frame length, so including the L2 header. On DWMAC4, if the len is exactly BUF_SIZE_8KiB, the next larger size is incorrectly selected. Lets fix the comparison and while at it, rename the parameter from len to mtu. Fixes: c3efed5ad1b0 ("net: stmmac: Enable dwmac4 jumbo frame more than 8KiB"). Signed-off-by: Maxime Chevallier Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260917215339.2022523-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0929addf483814e656e0a7c436da79b1c3d31268 Author: Andrew Halaney Date: Tue Apr 11 15:04:04 2023 -0500 net: stmmac: Remove some unnecessary void pointers [ Upstream commit 0c3f3c4f4b15a2c105e1ca882d100048074a2865 ] There's a few spots in the hardware interface where a void pointer is used, but what's passed in and later cast out is always the same type. Just use the proper type directly. Reviewed-by: Simon Horman Signed-off-by: Andrew Halaney Reviewed-by: Jesse Brandeburg Tested-by: Brian Masney Signed-off-by: Paolo Abeni Stable-dep-of: b42e7012773a ("net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K") Signed-off-by: Sasha Levin commit 1463f7ab572bb45ec182857ff44b060ff32e6303 Author: Maxime Chevallier Date: Thu Sep 17 23:53:35 2026 +0200 net: stmmac: selftests: Capture all packets for vlan checks [ Upstream commit 960db6f65788c21249ea04a947d5c01e38d19294 ] While we use vlan_vid_add to trigger the tag filtering machinery in the driver, there's no netdev associated to the VLAN. This causes the skb to arrive with empty skb->vlan_tci fields, as the packet is marked OTHERHOST in __netif_receive_skb_core(), and we fail our validation. Let's use the proxy mechanism introduced for DSA, that registers a ETH_P_ALL packet handler that runs earlier, before the vlan netdev lookup, then filters for the correct ethertype before passing an skb clone to our validation function. As we may receive external frames with the right tag from the outside, let's move the address check in the vlan validation function earlier. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18b9839d221d9006588012ac8c73452e654cee2d Author: Maxime Chevallier Date: Thu Sep 17 23:53:34 2026 +0200 net: stmmac: selftests: Check the dev->features for S-TAG offload testing [ Upstream commit ba804b23d76d278ee475b8427fa7c5623ce5e270 ] The S-TAG offload insertion incorrectly checks the dvlan (double vlan) DMA cap, which is different than S-TAG support. Use NETIF_F_HW_VLAN_STAG_TX to check if the feature is supported instead. Note that this flag isn't set in stmmac yet, but contrary to ARP offload, this is a feature that has a chance to get there eventually so let's leave the selftest here for now. It'll report -EOPNOTSUPP in the meantime. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a44dd3aa3218e2d058fd915691d4fdb884b145a0 Author: Maxime Chevallier Date: Thu Sep 17 23:53:32 2026 +0200 net: stmmac: selftests: Support running selftests on DSA conduits [ Upstream commit d68acbf93531abdb5b02b21994cd4c15a3c95b42 ] Most stmmac selftests rely on dev_add_pack() to add custom handlers, that validate the packets sent to ourselves through MAC loopback. However, when the stmmac-driven interface is a DSA CPU conduit, all frames that are received have ETH_P_XDSA as a protocol, even though they don't actually contain any tag as they come from the loopback and not the switch. This will prevent any incoming packet to match our packet handlers. Let's register a ETH_P_ALL packet handler when we detect that we're a DSA conduit, and use a proxy packet handler to filter the h_proto. As this allows external frames to be received through our .func(), the packet handler is added after the dev->addr field is populated in our selftest attributes. Note that we may still receive incoming packets from the switch, but these frames shouldn't interfere with the very specific frames used for selftests, and stmmac selftests in general aren't safe against external traffic interferences. This was validated on a WPQ864 devkit for IPQ8064, that has the SoC connected to a QCA8k switch. The ARP offload's packet handler is left alone, this feature is just not implemented in stmmac and due for removal. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e3ddcf4aeb342d4de2e5761c7042270d454752de Author: Emil Tsalapatis Date: Tue Sep 22 17:20:20 2026 +0000 bpf: Fix bpf_sock context code generation [ Upstream commit 4a4852376e3a2727ea40e61143d6d7c22bb6dfad ] Currently, the ctx access code reads the rx_queue_mapping field with either a 4-byte or 2-byte load. The rest of the bits in the register are marked known zero by the verifier. However, the emitted ctx access code places in the register on certain the special value (-1) using BPF_MOV_IMM64, which gets sign-extended to turn on all the bits in the register. By shifting this value right, the program ends up with a value at runtime above what the verifier assumes is possible. Fix this by ensuring the read value is as wide as the assumed size. Use MOV32 instructions instead of MOV64 instructions to keep the upper bits zero as assumed by the verifier. Also properly report the size of the destination variable (the bpf_sock field, 4 bytes) instead of the source (the socket field, 2 bytes). Fixes: c3c16f2ea6d2 ("bpf: Add rx_queue_mapping to bpf_sock") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260922172028.6269-4-emil@etsalapatis.com Signed-off-by: Sasha Levin commit 7b48daa3e5b43f72a8bfa98093f7891f877bd644 Author: bui duc phuc Date: Fri Sep 18 11:28:04 2026 +0700 net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error [ Upstream commit ac4334522e4ba4a3b6710dd5d4cc98092824b8ca ] pm_runtime_get_sync() leaves the runtime PM usage counter incremented even when it fails, but the error path in netcp_probe() does not call pm_runtime_put_noidle() to balance it, leaking a reference each time resume fails. Use pm_runtime_resume_and_get() instead, which automatically drops the usage counter on failure, fixing the leak. Fixes: 84640e27f230 ("net: netcp: Add Keystone NetCP core ethernet driver") Signed-off-by: bui duc phuc Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260918042804.13101-1-phucduc.bui@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ce86d6929d03e6b0abcb781dfa50f9f0816bff78 Author: Myeonghun Pak Date: Thu Sep 17 14:33:36 2026 -0400 tg3: clean up PHYLIB resources on probe failure [ Upstream commit a92e1a412c53dc0d9ad639e7abf8b3fc70a5b6ad ] tg3_get_invariants() can register an MDIO bus and connect a PHY for USE_PHYLIB devices. If tg3_init_one() later fails, its common error path releases the mappings and netdev without undoing those PHYLIB resources. Disconnect the PHY and unregister the MDIO bus before the remaining teardown. Guard PHY cleanup with USE_PHYLIB to match tg3_phy_init(), and call tg3_mdio_fini() unconditionally to match tg3_mdio_init(). The existing IS_CONNECTED and MDIOBUS_INITED flags make both helpers safe when initialization only completed partially. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 158d7abdae85 ("tg3: Add mdio bus registration") Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260917183336.36239-1-mhun512@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 92d88c88390fc62444c00a1a22078f838e03891f Author: Pengpeng Hou Date: Sun Sep 20 11:47:45 2026 +0800 net: usb: sr9700: include receive overhead in the length check [ Upstream commit c06bde80ae7a7b595732f7cabcb92cf08db9d56a ] The receive fixup subtracts the Ethernet CRC from the reported packet length, but compares that payload length against the whole remaining receive buffer. The following copy starts after the three-byte header, and the cursor advance consumes both that header and the four-byte CRC. Require the payload to fit after SR_RX_OVERHEAD before copying it or advancing to the next packet. The loop already ensures that the remaining buffer is larger than the overhead, so the subtraction is safe. The issue was found by our static-analysis tool. Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Reviewed-by: Ethan Nelson-Moore Tested-by: Ethan Nelson-Moore Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260920034745.18468-1-hppiscas@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76876fd26569302d26d91cbe8b75fa8e66cf8969 Author: Hui Peng Date: Sat Sep 19 11:25:14 2026 +0000 Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame() [ Upstream commit 6d91041bb38b97e2feb625123cc0529d7b83a0e1 ] While rfcomm_recv_frame() verifies that skb->len is at least sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2). When a 4-byte RFCOMM frame with EA == 0 arrives: 1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false). 2. Trimming the FCS byte decrements skb->len to 3. 3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns NULL without advancing skb->data. 4. Because the return value of skb_pull() is ignored, the un-pulled 3-byte struct rfcomm_hdr remains at skb->data and is either queued as application payload via rfcomm_recv_data() or parsed as a multiplexer control command via rfcomm_recv_mcc() on DLCI 0. Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len). Fixes: b230e5bf501c ("Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame") Assisted-by: LLM Signed-off-by: Hui Peng Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7af80ad2cebfe2f1879d6a39a1aaa061d9c4e1ca Author: Hui Peng Date: Sat Sep 19 22:17:38 2026 +0000 Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough [ Upstream commit f0ca020cbb9bb7f3f4ea8ba1dfcf30a282aec91e ] Fix multiple out-of-bounds reads in Bluetooth BNEP frame processing: 1. In bnep_rx_frame() and bnep_ctrl_frame() (net/bluetooth/bnep/core.c), use pskb_may_pull() to verify the BNEP header, control type byte, filter count, and extension headers exist before reading them, and return 0 after handling BNEP_CONTROL instead of falling through to Ethernet frame submission when no extension headers follow. 2. In bnep_net_xmit() (net/bluetooth/bnep/netdev.c), verify skb->len >= ETH_HLEN with pskb_may_pull() before reading the 14-byte Ethernet header to prevent an out-of-bounds heap read and infoleak on short AF_PACKET TX frames. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM Signed-off-by: Hui Peng Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d33d5ef8225538f76e4598c09e2074834667bb8d Author: Junrui Luo Date: Tue Sep 15 15:39:11 2026 +0800 drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl() [ Upstream commit 477bc3068fc3777b9d8ffd79e265b0dfdf2d3a6b ] virtio_gpu_resource_create_ioctl() calls drm_gem_object_release() on the drm_gem_handle_create() error path instead of dropping the reference it owns, so obj->funcs->free() never runs and the virtio_gpu_object, its pages and sg table, the resource id and the host-side resource are leaked. Use drm_gem_object_put() instead. Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support") Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-2-a0d799e4db66@outlook.com Signed-off-by: Sasha Levin commit 13423a058187c2039aa8cb235c916be4477221b7 Author: Junrui Luo Date: Tue Sep 15 15:39:10 2026 +0800 drm/virtio: fix object leak when drm_gem_handle_create() fails [ Upstream commit 36570ef2244cc4d7563b1f0157bc0f032498638c ] virtio_gpu_gem_create() owns the reference taken by virtio_gpu_object_create(). On the drm_gem_handle_create() error path it calls drm_gem_object_release() instead of dropping that reference. drm_gem_object_release() is the inverse of drm_gem_object_init() and does not touch the reference count or call obj->funcs->free(), so it is only correct as the last step of a destructor, as in virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1 with no remaining reference, so virtio_gpu_free_object() never runs and the shmem pages, sg table and virtio_gpu_object are leaked. Since virtio_gpu_object_create() has already set bo->created, VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side resource and the resource id. drm_gem_handle_create_tail() drops the handle reference on all of its internal error paths, so the caller only has to drop its own. Use drm_gem_object_put(), matching the success path below. Fixes: dc5698e80cf7 ("Add virtio gpu driver.") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-1-a0d799e4db66@outlook.com Signed-off-by: Sasha Levin commit d4fd251e3311727c32af89344d3332f788c153a2 Author: Jamal Hadi Salim Date: Thu Sep 17 06:57:32 2026 -0400 net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget [ Upstream commit 8a60ade2277e1f0e0d0578d565354e52292fa46d ] hfsc_classify() applies the "filter may only point downwards" level check only when the filter result carries no bound class. A filter created with a flowid gets res.class set once at bind time, so the check never runs for it during classification. hfsc_adjust_levels() can later raise a class's level without revalidating existing bindings, leaving two binds that were each legal at bind time pointing at each other; the classify walk then bounces between two interior classes forever with the qdisc lock held and BH disabled — a soft lockup from a single packet. The stuck walk trips the watchdog: watchdog: BUG: soft lockup - CPU#3 stuck for 13s! [ping:444] RIP: 0010:u32_classify+0x542/0x17f0 ... tcf_classify+0x66/0xa0 hfsc_enqueue+0x166/0xdf0 Bound the traversal with a budget of non-descending hops, the only way a configured walk can move without descending the class tree once levels drift after bind time. The budget is cumulative over the whole walk and is deliberately not reset on a descending hop: a chain that alternates a descent with a lateral hop would return the budget every lap and never trip. Descending hops never decrement it, so legitimately deep trees are unaffected and a terminating lateral chain still classifies normally. Drop the packet with a rate-limited warning once the budget is exhausted, mirroring the merged HTB fix. This is a follow-up to commit 729c4896ab82 ("net/sched: sch_htb: limit htb_classify inner-class filter hops"), which bounded the same classify loop on the HTB side but left the HFSC walk unbounded. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HFSC, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Build a cycle with two legal-at-bind-time flowid binds and a level drift: class X 1:1 (child of root) with leaf child 1:10; class Y 1:2 (sibling of X) with children 1:20 and 1:200; root u32 filter flowid 1:1; filter on X flowid 1:2 (legal when Y is a leaf); after Y's level rises to 2, filter on Y flowid 1:1 (legal then). Send one packet (ping on the device). Unfixed kernel: classify spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). Fixes: a2f79227138c ("net_sched: sch_hfsc: fix classification loops") Reported-by: Sashiko (gemini + nipa) Closes: https://lore.kernel.org/netdev/QDISC-CTUU.v2.20260913192614@mojatatu.com/ Link: https://sashiko.dev/#/patchset/QDISC-CTUU.v2.20260913192614@mojatatu.com Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/QDISC-CTUU.v2.20260913192614%40mojatatu.com Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-CTUU.v3.20260916184908@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3942557938f846e7481f6ccb2b41ccbdee61baa1 Author: Aamir Ahmed Date: Tue Sep 15 00:06:58 2026 +0100 net: usb: catc: bound the RX packet length in catc_rx_done() [ Upstream commit 9d565b6b72fe3f41fd43636e143072848105189f ] catc_rx_done() walks a multi-packet URB, reading a two-byte length from each packet header. Its bound, pkt_len > urb->actual_length, ignores the header offset and compares against the whole transfer rather than the bytes left from pkt_start, so a crafted packet header makes skb_copy_to_linear_data() read past the buffer. A length below ETH_HLEN is also accepted, including zero, and eth_type_trans() then reads a MAC header from the uninitialised tailroom of a shorter skb. The is_f5u011 branch takes its length straight from the transfer, so a zero-length URB reaches the same path. Track the bytes remaining from the current packet, and reject a header that does not fit, a length past what is left, and a length below an Ethernet header. A transfer shorter than an Ethernet header, including a zero-length one, previously became a runt skb passed to netif_rx() and counted as received; it is now counted in rx_length_errors and ends the walk. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Aamir Ahmed Reviewed-by: Simon Horman Link: https://patch.msgid.link/AS8P251MB00015FD7716F38C345619B56C8BB2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3fe624c3843694ab096fdb198526ba0c659febbe Author: Yiqi Sun Date: Tue Sep 15 17:50:17 2026 +0800 sctp: avoid livelock while updating retransmit path [ Upstream commit d2c31b837406395e576afeb25958c98e9938f3f6 ] sctp_assoc_update_retran_path() can loop forever when every remaining transport, including retran_path, is SCTP_UNCONFIRMED: the state check runs before the wraparound test, so the loop cannot observe that it has completed a full pass. Fix this by considering a transport only when it is not UNCONFIRMED, then checking whether the walk has returned to retran_path. This makes the full-pass termination independent of the transport state while preserving the existing fallback selection semantics. Also restore the NULL guard around the retran_path assignment. In the all-UNCONFIRMED case there is no eligible replacement transport, and installing NULL would leave later retransmit-path users and the debug print with a NULL path. Fixes: 4c47af4d5eb2 ("net: sctp: rework multihoming retransmission path selection to rfc4960") Signed-off-by: Yiqi Sun Acked-by: Xin Long Link: https://patch.msgid.link/20260915095017.942213-1-sunyiqixm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae38c2e0294a4b7162e02e4b4936aea3345bbc92 Author: Kuniyuki Iwashima Date: Wed Sep 16 23:09:24 2026 +0000 ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink(). [ Upstream commit dd47bcf279f1083f09bf5266890b26263361022b ] The cited commit accidentally added ip6gre_tunnel_unlink_md() in ip6erspan_changelink(). Let's correct it to ip6erspan_tunnel_unlink_md(). Fixes: b80d0b93b991 ("net: ip6_gre: fix tunnel metadata device sharing.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260916230927.378957-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4b9bc21b2396c396d88dd909caaf73d5be6ff593 Author: Jérémy Jean Date: Tue Sep 15 12:48:07 2026 +0000 net: gue: reject invalid REMCSUM offsets [ Upstream commit 2566866fc30965d915d0b52b5c3323b362619f0e ] The REMCSUM option carries an absolute checksum start and checksum field offset. gue_remcsum() passes them to skb_remcsum_process(), whose partial path stores offset - start in the u16 skb->csum_offset variable. If offset is less than start, this underflows. A forwarded packet can retain CHECKSUM_PARTIAL and reach a NETIF_F_HW_CSUM driver which trusts the metadata, leading skb_copy_and_csum_dev() to write two bytes about 64 KiB beyond the destination buffer. Reject reversed tuples in validate_gue_flags(), after the existing length validation, so all GUE parsers enforce the ordering in one place. Fixes: fe881ef11cf0 ("gue: Use checksum partial with remote checksum offload") Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260915124806.2852293-2-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e8fcf3f08834e939b797311742ee72b1e2a08096 Author: Nguyen Ngoc Thang Date: Tue Sep 15 22:08:16 2026 +0700 net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure [ Upstream commit 47abe7a5c4eb53269aca3506446f851572a059a3 ] flow_offload_alloc() returns NULL when the conntrack entry is dying (e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation fails; both are expected under load and neither is a kernel bug. This path runs from softirq on every committed packet, so with panic_on_warn=1 an unprivileged user can panic the box just by racing a conntrack flush against a `tc ... action ct commit` classifier. Reproduced with a custom repro under QEMU: a small, fixed set of UDP flows through `tc filter ... action ct commit` on lo, raced against threads flooding bare ctnetlink CT_DELETE (flush) requests. Hits WARNING: net/sched/act_ct.c:437 (tcf_ct_flow_table_add(), inlined into tcf_ct_act() in this build) within ~15s on the unpatched kernel; same setup is clean on the patched kernel. The fix itself is behavior-preserving: both branches already did `goto err_alloc` before and after, only the WARN is removed. Fixes: 64ff70b80fd4 ("net/sched: act_ct: Offload established connections to flow table") Reported-by: syzbot+6cc37aba98dac721c415@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6cc37aba98dac721c415 Signed-off-by: Nguyen Ngoc Thang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915150816.36487-1-ngocthang2710.1999@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98a7c8dbe1b491ae15e8eae2c7a123441b6ea741 Author: Francesco Magazzu Date: Fri Sep 18 15:16:20 2026 +0200 drm/nouveau/clk: don't clobber reclock status when restoring volt/fan [ Upstream commit e5cccdafc855cd5f96f4b51d38114a0360b075d7 ] nvkm_cstate_prog() reuses 'ret' for the voltage and fan-speed restore calls it makes after reprogramming the clocks. Those calls almost always succeed, so the status of the reclock itself is overwritten and the function reports success even when clk->func->calc() or clk->func->prog() failed. The converse is also true: a successful reclock is reported as an error if the final restore call fails, even though that failure is only logged and otherwise ignored. The only consumer of the return value is the error message in nvkm_pstate_work(), so in practice a failing reclock is simply never reported. Nothing else changes, but a function that returns success on failure is a trap for the next caller. Keep the calc/prog status in 'ret' and use a separate local for the restore calls. Fixes: 3eca809b3c05 ("drm/nouveau/clk: cosmetic changes") Signed-off-by: Francesco Magazzu Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260918131620.405133-5-postadelmaga@gmail.com Signed-off-by: Sasha Levin commit db5dd9f47b4df1be322f498d846e9a82940a7390 Author: Dan Carpenter Date: Fri Sep 18 15:16:17 2026 +0200 drm/nouveau/clk: fix list cursor use after loop in nvkm_clk_ustate_update [ Upstream commit aff09d9e37e02dc60bde79035ac15b136d602259 ] If list_for_each_entry() exits without hitting a break then "pstate" is not a valid pstate pointer. Introduce a "found" variable instead. The check is reachable from userspace: nvkm_clk_ustate_update() takes the pstate id straight from the 'pstate' debugfs file, so requesting an id that is not in clk->states - or any id at all when the perf tables are broken and the list is empty - makes the pstate->pstate != req test dereference the list head cast to a struct nvkm_pstate, which is an out-of-bounds read. Fixes: 7c8565220697 ("drm/nouveau/clk: implement power state and engine clock control in core") Signed-off-by: Dan Carpenter [Francesco: rebased on drm-misc-next, expanded the commit message] Signed-off-by: Francesco Magazzu Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260918131620.405133-2-postadelmaga@gmail.com Signed-off-by: Sasha Levin commit 7925f500114909501764ec5bcc02c4ee5949e532 Author: Joseph Qi Date: Fri Sep 4 10:37:51 2026 +0800 ocfs2: make ocfs2_calc_xattr_init() return void [ Upstream commit 525c0edc032b3297d0c1056cf1fa20cf1f9e6184 ] ocfs2_calc_xattr_init() used to read the default ACL off the parent inode itself, so it could return an error from ocfs2_xattr_get_nolock(). Commit bd7c05fb4a47 ("ocfs2: fix circular locking dependency in ocfs2_init_acl()") moved that lookup before the transaction starts and deleted the error path, but left the now vestigial 'int ret = 0' declaration and both 'return ret' statements behind, along with an unreachable error branch in ocfs2_mknod(). Drop the leftover variable and convert the return type to void, so the callee states that it always succeeds and the caller no longer carries a check that can never trigger. No functional change. Link: https://lore.kernel.org/20260904023751.3703334-1-joseph.qi@linux.alibaba.com Fixes: bd7c05fb4a47 ("ocfs2: fix circular locking dependency in ocfs2_init_acl()") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609040247.8B3lmoqX-lkp@intel.com/ Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Sasha Levin commit a174ae458c082a06c719c005c0682080b6a94ac6 Author: Julian Anastasov Date: Fri Sep 11 14:43:15 2026 +0300 ipvs: revalidate ihl before icmp_send [ Upstream commit e290145564886d6a3038810c621f738c1fe9fa51 ] While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent possible out-of-bounds access. One such place reported by Sashiko is ip_vs_in_icmp() where local process can change the ihl field and after pskb_may_pull() we can see larger value. Even if icmp_send() has checks to prevent out-of-bounds access, play safe and add check to drop the packet if the ihl field is changed. As the outer headers are pulled, make sure the transport header is updated too, it was used before commit 7fcc2fe39fed ("net: icmp: avoid invalid transport header access in icmp_send tracepoint") Fixes: f2edb9f7706d ("ipvs: implement passive PMTUD for IPIP packets") Link: https://sashiko.dev/#/patchset/20260806105211.34622-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9fa1f367f1fe2a6bf5f37125b38a72b3ea2aa5aa Author: Karl Mehltretter Date: Thu Sep 10 22:02:28 2026 +0200 netfilter: nft_synproxy: use the family-aware checksum helper [ Upstream commit a311a898172743558b82f6035ef2aa8c310a4223 ] nft_synproxy_do_eval() verifies the TCP checksum before it switches on skb->protocol. It uses nf_ip_checksum(), which constructs an IPv4 pseudo header and relies on the IPv4 header checksum when folding the whole skb. Neither operation is valid for an IPv6 packet. A correctly checksummed IPv6 segment can therefore fail verification when it reaches the hook as CHECKSUM_NONE or, at NF_INET_LOCAL_IN, CHECKSUM_COMPLETE. nft_synproxy_do_eval() returns NF_DROP before nft_synproxy_eval_v6() can send a SYN-ACK. nft_synproxy_validate() deliberately admits NFPROTO_IPV6 and NFPROTO_INET, and the xtables counterpart ip6t_SYNPROXY.c already calls nf_ip6_checksum(). Use nf_checksum() with nft_pf() so the checksum helper dispatches to the packet family's implementation. Fixes: ad49d86e07a4 ("netfilter: nf_tables: Add synproxy support") Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 46432f2e76f7c385d82506304a2928e7d293289f Author: Florian Westphal Date: Thu Sep 3 02:41:46 2026 +0200 netfilter: nfnetlink_queue: hold nfnl mutex in event notifier [ Upstream commit 9461613afc59acef44a0071b0dd5075f6e993ffe ] We must serialize the release notifier and the config netlink function. A concurrent thread can issue close() which can call the release function while unrelated socket processes UNBIND request for same portid: Oops: general protection fault, [..] RIP: 0010:__instance_destroy+0x60/0x210 [nfnetlink_queue] Call Trace: nfqnl_recv_config+0x9b0/0xdc0 [nfnetlink_queue] nfnetlink_rcv_msg+0x7c2/0xeb0 ? __pfx_nfnetlink_rcv_msg+0x10/0x10 After this, parallel UNBIND and URELEASE events are impossible. This change isn't nice, but its the shortest fix given instances are not refcounted and the nfnetlink config callback drops the rcu read lock early due to need for sleeping allocations. Fixes: 7af4cc3fa158 ("[NETFILTER]: Add "nfnetlink_queue" netfilter queue handler over nfnetlink") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 997495185c65ce79618d158160d08be3bce4e6a2 Author: Scott Mitchell Date: Sat Jan 17 09:32:30 2026 -0800 netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC -> GFP_KERNEL_ACCOUNT allocation [ Upstream commit a4400a5b343d1bc4aa8f685608515413238e7ee2 ] Currently, instance_create() uses GFP_ATOMIC because it's called while holding instances_lock spinlock. This makes allocation more likely to fail under memory pressure. Refactor nfqnl_recv_config() to drop RCU lock after instance_lookup() and peer_portid verification. A socket cannot simultaneously send a message and close, so the queue owned by the sending socket cannot be destroyed while processing its CONFIG message. This allows instance_create() to allocate with GFP_KERNEL_ACCOUNT before taking the spinlock. Suggested-by: Florian Westphal Signed-off-by: Scott Mitchell Signed-off-by: Florian Westphal Stable-dep-of: 9461613afc59 ("netfilter: nfnetlink_queue: hold nfnl mutex in event notifier") Signed-off-by: Sasha Levin commit f92e8f39726ba68a7c42c6b7566be687c8161579 Author: Jérémy Jean Date: Tue Aug 18 20:00:15 2026 +0000 netfilter: flowtable: publish HW_DEAD after worker is done [ Upstream commit d644b23afe1ef509c9961a6d84a093c2587edf02 ] flow_offload_work_del() sets NF_FLOW_HW_DEAD before the work handler clears NF_FLOW_HW_PENDING. Once a flow is both HW_DYING and HW_DEAD, a concurrent garbage collection pass can remove it and schedule it for RCU freeing. The offload worker holds neither an RCU read lock nor a reference to the flow. If it is preempted after publishing HW_DEAD, the RCU callback can free the flow before the worker resumes and clears HW_PENDING, resulting in a use-after-free. Move HW_DEAD publication to the common worker epilogue after the pending bit is cleared, making it the final flow access by destroy work. Order all preceding flow accesses before publishing the bit that allows garbage collection to free the object. Fixes: 2c8897953f3b ("netfilter: flowtable: Add pending bit for offload work") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 238c7e7e0808bd8c8397e3831760654b95349f5e Author: Vlad Buslov Date: Wed Feb 1 17:30:56 2023 +0100 netfilter: flowtable: allow unidirectional rules [ Upstream commit 8f84780b84d645d6e35467f4a6f3236b20d7f4b2 ] Modify flow table offload to support unidirectional connections by extending enum nf_flow_flags with new "NF_FLOW_HW_BIDIRECTIONAL" flag. Only offload reply direction when the flag is set. This infrastructure change is necessary to support offloading UDP NEW connections in original direction in following patches in series. Signed-off-by: Vlad Buslov Signed-off-by: David S. Miller Stable-dep-of: d644b23afe1e ("netfilter: flowtable: publish HW_DEAD after worker is done") Signed-off-by: Sasha Levin commit c6d5c582d55a8f229d75e98d62eaa065b0deb18d Author: Zhiling Zou Date: Fri Sep 11 00:18:24 2026 +0800 xsk: Use a 32-bit compare in xsk_map_gen_lookup [ Upstream commit 70504de0bb627848667207bec7ccfd647deb8814 ] xsk_map_gen_lookup() loads a u32 key and compares it with max_entries using BPF_JMP_IMM. BPF immediates are sign-extended to 64 bits, so a max_entries value of 0x80000000 or higher becomes a threshold larger than every zero-extended 32-bit key. An out-of-range index then skips the bounds check and the generated lookup reads past xsk_map[]. Compare with BPF_JMP32_IMM so the check stays in 32-bit unsigned range. Fixes: e65650f291ee ("bpf: Implement map_gen_lookup() callback for XSKMAP") Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Alexei Starovoitov Reviewed-by: Emil Tsalapatis Link: https://patch.msgid.link/7d2cb8e8dfaa9eb8fdff85156987a60960787dc3.1789056660.git.zhilinz@nebusec.ai Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 2f9564c5a7cf57b577c46adfc14898ce5cd0ec20 Author: Karl Mehltretter Date: Mon Sep 7 07:58:47 2026 +0200 s390/pci/docs: Fix sriov_numvfs attribute name [ Upstream commit 4525a911049543c23885a540a788d13be318a486 ] The attribute is sriov_numvfs (drivers/pci/iov.c); the document names it sriov_numvf, which does not exist. Use sriov_numvfs. Fixes: de267a7c71ba ("s390/pci: Documentation for zPCI") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Randy Dunlap Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 0012388c40e76ac67e1e8bee4de15e86952b6a74 Author: Niklas Schnelle Date: Tue Apr 7 15:24:45 2026 +0200 docs: s390/pci: Improve and update PCI documentation [ Upstream commit 737c4f4a241ca85c597ca2ef1a6f8446bf681ab5 ] Update the s390 specific PCI documentation to better reflect current behavior and terms such as the handling of Isolated VFs via commit 25f39d3dcb48 ("s390/pci: Ignore RID for isolated VFs"). Add a descriptions for /sys/firmware/clp/uid_checking which was added in commit b043a81ce3ee ("s390/pci: Expose firmware provided UID Checking state in sysfs") but missed documentation. Similarly add documentation for the fidparm attribute added by commit 99ad39306a62 ("s390/pci: Expose FIDPARM attribute in sysfs") and add a list of pft values and their names. Finally improve formatting of the different attribute descriptions by adding a separating colon. Reviewed-by: Farhan Ali Acked-by: Randy Dunlap Tested-by: Randy Dunlap Reviewed-by: Matthew Rosato Signed-off-by: Niklas Schnelle Reviewed-by: Gerd Bayer Link: https://lore.kernel.org/r/20260407-uid_slot-v8-1-15ae4409d2ce@linux.ibm.com Signed-off-by: Vasily Gorbik Stable-dep-of: 4525a9110495 ("s390/pci/docs: Fix sriov_numvfs attribute name") Signed-off-by: Sasha Levin commit 80f417cb6989d6aae3c7c140bf4d246b7c67f890 Author: Randy Dunlap Date: Wed Feb 8 23:13:51 2023 -0800 Documentation: s390: correct spelling [ Upstream commit ac56c666f80df0b1dc9c3ef53d0798b74629a116 ] Correct spelling problems for Documentation/s390/ as reported by codespell. Signed-off-by: Randy Dunlap Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20230209071400.31476-16-rdunlap@infradead.org Signed-off-by: Heiko Carstens Stable-dep-of: 4525a9110495 ("s390/pci/docs: Fix sriov_numvfs attribute name") Signed-off-by: Sasha Levin commit 4cae8e153b49065cb057510da8911575a99a6cfe Author: Niklas Schnelle Date: Wed Feb 24 11:29:36 2021 +0100 s390/pci: expose UID uniqueness guarantee [ Upstream commit 408f2c9c15682fc21b645fdec1f726492e235c4b ] On s390 each PCI device has a user-defined ID (UID) exposed under /sys/bus/pci/devices//uid. This ID was designed to serve as the PCI device's primary index and to match the device within Linux to the device configured in the hypervisor. To serve as a primary identifier the UID must be unique within the Linux instance, this is guaranteed by the platform if and only if the UID Uniqueness Checking flag is set within the CLP List PCI Functions response. While the UID has been exposed to userspace since commit ac4995b9d570 ("s390/pci: add some new arch specific pci attributes") whether or not the platform guarantees its uniqueness for the lifetime of the Linux instance while defined is not visible from userspace. Remedy this by exposing this as a per device attribute at /sys/bus/pci/devices//uid_is_unique Keeping this a per device attribute allows for maximum flexibility if we ever end up with some devices not having a UID or not enjoying the guaranteed uniqueness. Signed-off-by: Niklas Schnelle Reviewed-by: Viktor Mihajlovski Signed-off-by: Heiko Carstens Stable-dep-of: 4525a9110495 ("s390/pci/docs: Fix sriov_numvfs attribute name") Signed-off-by: Sasha Levin commit 8c3b8496fa20975b2a74b0bb3170d7cc2a36bff0 Author: Christiano Amora Date: Wed Sep 16 10:46:22 2026 -0300 Bluetooth: SMP: reject Security Request over BR/EDR [ Upstream commit f033482d76a9f18080c7a40c5f9c678bd7adc8f3 ] Bose QC Ultra Headphones (dual-mode, same public address on both transports) occasionally send an SMP Security Request on the BR/EDR SMP fixed channel right after the ACL link is encrypted. The kernel handles it as if it were an LE link: smp_cmd_security_req() has no transport check, smp_ltk_encrypt() looks up an LTK with the ACL connection's dst_type, and hci_find_ltk() matches the peer's LE LTK because the LE public address type is stored as ADDR_LE_DEV_PUBLIC (0), the same value as BDADDR_BREDR. HCI_OP_LE_START_ENC is then issued on the ACL handle, the controller rejects it with Invalid HCI Command Parameters, and hci_cs_le_start_enc() disconnects the link with HCI_ERROR_AUTH_FAILURE. The headphones drop within a second of connecting, before any profile is up; a manual reconnect works. btmon (MediaTek MT7922, kernel 7.0.12): > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 50 Address: BC:87:FA:47:73:5E (Bose Corporation) Encryption: Enabled with AES-CCM (0x02) > ACL Data RX: Handle 50 flags 0x02 dlen 6 BR/EDR SMP: Security Request (0x0b) len 1 Authentication requirement: No bonding, No MITM, SC (0x08) < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 Handle: 50 Address: BC:87:FA:47:73:5E (Bose Corporation) > HCI Event: Command Status (0x0f) plen 4 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Invalid HCI Command Parameters (0x12) < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 50 Address: BC:87:FA:47:73:5E (Bose Corporation) Reason: Authentication Failure (0x05) SMP over BR/EDR is limited to cross-transport key derivation; the Security Request procedure (Core Specification Vol 3, Part H, Section 2.4.6, PDU in Section 3.6.7) has no BR/EDR counterpart. Reply with Pairing Failed / Command Not Supported on a non-LE link, before the PDU is parsed, and keep the connection. The reply is sent directly rather than through smp_failure(): rejecting a command on the wrong transport is not an authentication failure, and MGMT_EV_AUTH_FAILED would make bluetoothd disconnect the device. Tested on the affected host (kernel 7.0.12, MediaTek MT7922, Bose QC Ultra) with the patched module built out of tree: 7 days and 49 reconnects without a drop, against 2 drops in the 3 days before the patch. Every disconnect in that week had a userspace or remote reason. Fixes: b5ae344d4c0f ("Bluetooth: Add full SMP BR/EDR support") Assisted-by: LLM Signed-off-by: Christiano Amora Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b02948a23455f8190a53887b2d2c13ae1d360cea Author: Ran Hongyun Date: Mon Jul 13 19:55:25 2026 +0800 squashfs: Add dictionary size range check to prevent shift-out-of-bounds [ Upstream commit 1f7745fb3580152ca902ef181b605f33cabfb1d0 ] When an abnormal SquashFS image (COMP_OPTS flag is 1 but dictionary size is 0) is mounted, and performs shift operations using dictionarysize, the shift exponent is -1, causing a shift-out-of-bounds. Detail as below: squashfs_comp_opts(msblk, buffer, length) squashfs_xz_comp_opts() if (comp_opts) n = ffs(opts->dict_size) - 1;<----opts->dict_size=0, n=-1 if (opts->dict_size != (1 << n) && opts->dict_size != (1 << n) + (1 << (n + 1))) <----shift-out-of-bounds Fix it by adding a dictionary size range check before the shift operation. Fixes: ff750311d30a ("Squashfs: add compression options support to xz decompressor") Signed-off-by: Ran Hongyun Link: https://patch.msgid.link/20260713115525.2661734-1-ranhongyun1@huawei.com Reviewed-by: Phillip Lougher Reviewed-by: Zhihao Cheng Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0c796efa919f52f788c22c79d1f1b70321696b3d Author: Jiayuan Chen Date: Thu Sep 3 18:09:20 2026 +0800 bpf: Fix out-of-bounds read of rtt_min in sock_ops [ Upstream commit 75f8cf22463d82bb1fb0239a3d485fc8f4c8ef03 ] A sockops prog reading skops->rtt_min never checks the sk type: on the tcp_conn_request() path sock_ops->sk is a request_sock (non-full), and the ctx rewrite casts it to a tcp_sock (full) and reads rtt_min past the end of the request_sock, returning dirty adjacent memory. SEC("sockops") int prog(struct bpf_sock_ops *skops) { switch (skops->op) { case BPF_SOCK_OPS_RWND_INIT: leak = skops->rtt_min; /* reads the request_sock OOB */ ... } } For instance one such read returned rtt_min=0xffff8881, the high half of a leaked kernel pointer. Guarding that cast is exactly what SOCK_OPS_GET_FIELD() does -- it checks is_locked_tcp_sock and returns 0 when sock_ops->sk is not a locked full socket. Every other tcp_sock field in sock_ops goes through it; rtt_min is the only one open-coded, so it skips the check. Read rtt_min through SOCK_OPS_GET_FIELD() too. rtt_min is a bit special: it is a struct minmax and we only want the current min, so pass rtt_min.s[0].v. That is equivalent to the old hand-computed offset offsetof(struct tcp_sock, rtt_min) + sizeof_field(struct minmax_sample, t) (s[0] sits at rtt_min + 0 and .v at + sizeof(.t), i.e. what minmax_get() returns), so the loaded field is unchanged and only the full-sock guard is added. The two BUILD_BUG_ON()s that protected the hand-computed offset are no longer needed. Before patch: 0: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 1: r1 = *(u32 *)(r1 +2324) ; ((tcp_sock *)sk)->rtt_min.s[0].v After patch: 0: *(u64 *)(r1 +56) = r9 1: r9 = *(u8 *)(r1 +50) ; is_locked_tcp_sock 2: if r9 == 0 goto pc+4 ; not a locked full sock -> 0 3: r9 = *(u64 *)(r1 +56) 4: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 5: r1 = *(u32 *)(r1 +2324) ; rtt_min.s[0].v 6: goto pc+2 7: r9 = *(u64 *)(r1 +56) 8: r1 = 0 Fixes: 44f0e43037d3 ("bpf: Add support for reading sk_state and more") Reported-by: VEGA Signed-off-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260903100921.113374-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 40660b023bc247713bc5cf8fffe6f6313fd83183 Author: Sven Schnelle Date: Wed Sep 9 11:29:53 2026 +0200 selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tc [ Upstream commit d22c3e0088e85be8131f7a9283f759cdbb20726d ] The current regex also matches symbols in modules, which makes the test fail on s390 where name_show is present only once in the kernel, but also multiple times in modules: 000001b1401cdc20 t name_show 000001b0c05e6c40 t name_show [mdev] 000001b0c0495f30 t name_show [i2c_core] Fix this by changing the regular expression to only match the function name. Link: https://lore.kernel.org/all/20260909092954.2200558-1-svens@linux.ibm.com/ Fixes: 03b80ff8023a ("selftests/ftrace: Add new test case which checks non unique symbol") Signed-off-by: Sven Schnelle Reviewed-by: Steven Rostedt Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 0f38472a2aa8704a6b514c0dfa9c32f3672b8f32 Author: Weiming Shi Date: Wed Sep 9 12:08:08 2026 +0800 bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL [ Upstream commit e4a62833adff6ef0fe7c0b90393204fe3c26b5c5 ] An LWT_SEG6LOCAL program can invalidate its cached SRH with bpf_lwt_seg6_adjust_srh() and then call bpf_skb_pull_data(). The latter may reallocate skb->head, leaving the per-CPU SRH pointer dangling. Post-program SRH validation then writes through that pointer. Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL programs so the verifier rejects this unsafe helper combination. Other LWT program types continue to expose the helper through lwt_out_func_proto(). Fixes: 004d4b274e2a ("ipv6: sr: Add seg6local action End.BPF") Reported-by: co+adfca3e91be95776@bugs.sh Suggested-by: Alexei Starovoitov Signed-off-by: Weiming Shi Signed-off-by: Daniel Borkmann Reviewed-by: Emil Tsalapatis Closes: https://lore.kernel.org/all/GCy0KRM2IcQGoJQTjJEU9D0maBxXzEDHuQpq@bugs.sh/ Link: https://lore.kernel.org/bpf/DL9COXZQXX4V.1FN45QO2Q77ZH@gmail.com/ Link: https://lore.kernel.org/bpf/20260909040807.3885815-2-bestswngs@gmail.com Signed-off-by: Sasha Levin commit f54b20091e639d95bdefcc43ff145746c07afce2 Author: Daniel Borkmann Date: Mon Sep 7 14:10:24 2026 +0200 bpf: Fix bpf_skb_change_tail wrt csum partial skbs [ Upstream commit 3b55f350c68a0aceff108f47f9d31f47ebffaf7b ] Cilium generates ICMP "frag needed" replies from BPF when a LB DSR packet exceeds the egress MTU. The reply is built by first trimming the packet down to target size via bpf_skb_change_tail(), and then pushing the ICMP error headers in front of it. The trim is rejected for skbs which carry a checksum offload, e.g. TCP packets aggregated by GRO on ingress where tcp_gro_complete() leaves the skb as CHECKSUM_PARTIAL. __bpf_skb_min_len() raises the minimum length to the end of the L4 checksum field, so a trim to 42 bytes bails out with -EINVAL given a min_len of 52 in this case, and due to that the ICMP generator fails. This is not the case if GRO is turned off. Fix this bpf_skb_change_tail() restriction and drop the checksum offload when the new length no longer covers the checksum field. The BPF program rewrites the skb into an ICMP error and computes the checksum itself anyway. Fixes: 5293efe62df8 ("bpf: add bpf_skb_change_tail helper") Reported-by: Tom Hadlaw Reported-by: Yusuke Suzuki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260907121025.1923656-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cd366b9091a3e6ed8229e4b908e895d20b527dc0 Author: NeilBrown Date: Thu Sep 24 18:06:25 2026 +0200 SUNRPC: lock against ->sock changing during sysfs read [ Upstream commit b49ea673e119f59c71645e2f65b3ccad857c90ee ] ->sock can be set to NULL asynchronously unless ->recv_mutex is held. So it is important to hold that mutex. Otherwise a sysfs read can trigger an oops. Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before handling sysfs reads") appears to attempt to fix this problem, but it only narrows the race window. [ Removed the changes about net/sunrpc/sysfs.c, as this file doesn't exist in 5.10 ] Fixes: 17f09d3f619a ("SUNRPC: Check if the xprt is connected before handling sysfs reads") Fixes: a8482488a7d6 ("SUNRPC query transport's source port") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Robert Garcia Signed-off-by: Greg Kroah-Hartman Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit b7c074d21fe8a8ee3b4f866a12c72cad6a5826eb Author: Vitaly Kuznetsov Date: Thu Sep 24 20:39:21 2026 +0000 HID: hyperv: streamline driver probe to avoid devres issues commit 66ef47faa90d838cda131fe1f7776456cc3b59f2 upstream It was found that unloading 'hid_hyperv' module results in a devres complaint: ... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not. The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct. Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is. Fixes: 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") Suggested-by: Michael Kelley Signed-off-by: Vitaly Kuznetsov Reviewed-by: Michael Kelley Tested-by: Saurabh Sengar Signed-off-by: Jiri Kosina [ 5.10: context adjusted only - mousevsc_ll_driver is non-const in 5.10 because the hid_ll_driver constification (d38213a911c5 "HID: hyperv: Constify lowlevel HID driver") is not present; the applied diff is identical to the upstream commit, no functional change ] Signed-off-by: Suraj Jitindar Singh Signed-off-by: Sasha Levin commit 30bcd2d69ca9f3b7c625bfb3c7aa7637cae25320 Author: Jinjie Ruan Date: Mon Aug 26 20:14:20 2024 +0800 spi: zynqmp-gqspi: Use devm_spi_alloc_host() [ Upstream commit 64640f6c972e80f52196416a8d4dc3c0ffcbc82d ] Use devm_spi_alloc_host() so that there's no need to call spi_controller_put() in the error path. Signed-off-by: Jinjie Ruan Acked-by: Michal Simek Link: https://patch.msgid.link/20240826121421.3384792-2-ruanjinjie@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0fe696148d2c6486e52220aab822135ed7d05f38 Author: Benoît Sevens Date: Tue Sep 22 08:16:14 2026 +0000 HID: logitech-hidpp: fix race condition when accessing stale stack pointer commit e2aaf2d3ad92ac4a8afa6b69ad4c38e7747d3d6e upstream. The driver uses hidpp->send_receive_buf to point to a stack-allocated buffer in the synchronous command path (__do_hidpp_send_message_sync). However, this pointer is not cleared when the function returns. If an event is processed (e.g. by a different thread) while the send_mutex is held by a new command, but before that command has updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will observe that the mutex is locked and dereference the stale pointer. This results in an out-of-bounds access on a different thread's kernel stack (or a NULL pointer dereference on the very first command). Fix this by: 1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex in the synchronous command path. 2. Moving the assignment of the local 'question' and 'answer' pointers inside the mutex_is_locked() block in the handler, and adding a NULL check before dereferencing. Fixes: 2f31c5252910 ("HID: Introduce hidpp, a module to handle Logitech hid++ devices") Cc: stable@vger.kernel.org Signed-off-by: Benoît Sevens Signed-off-by: Jiri Kosina [Lee: Clear hidpp->send_receive_buf at exit label in hidpp_send_message_sync() as __do_hidpp_send_message_sync() was split out later in 60165ab774cb] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit fff3c7b9130e98d6f64cbeb42091b39e422fa1b8 Author: Guangshuo Li Date: Sun Sep 13 16:58:14 2026 +0800 drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure commit f4fae975db08a9aeec0b15e145c7d4d0fe02a0ec upstream. msm_hdmi_phy_probe() enables runtime PM before enabling the PHY resources and initializing the PLL, but failures from either operation return without calling the matching pm_runtime_disable(). The remove path disables runtime PM, but it is not called when probe fails. As a result, runtime PM remains enabled after an unsuccessful probe. Route failures after pm_runtime_enable() through a common error path and disable runtime PM before returning. This issue was found by manual code inspection. Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/753043/ Link: https://lore.kernel.org/r/20260913085814.1509352-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 4a4eef2c66edcd2d5a7c2498c0c858316b2bb5d7 Author: Guangshuo Li Date: Sat Aug 8 21:16:24 2026 +0800 drm/msm/adreno: fix autosuspend cleanup during teardown commit 6fbbf1e152f34ad3913e4a6476680aba672c5068 upstream. adreno_gpu_init() calls pm_runtime_use_autosuspend(), but adreno_gpu_cleanup() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to adreno_gpu_cleanup(). This issue was found by manual code inspection. Fixes: eeb754746b14 ("drm/msm/gpu: use pm-runtime") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/745110/ Link: https://lore.kernel.org/r/20260808131624.2854412-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 4ba86c44b2fcb1c3175caa2456b6d58f483446ab Author: Rik van Riel Date: Sat Aug 8 10:47:55 2026 -0400 wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver commit da2ca406f45a6e21760243152ed8d2e8e72915c2 upstream. ieee80211_set_bitrate_mask() checks if the interface is running via ieee80211_sdata_running(), but it does not check if the interface is still present in the driver. When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, the call reaches drv_set_bitrate_mask() in driver-ops.h which hits wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows wext_ioctl_dispatch() in wext-core.c dispatching the ioctl, calling ioctl_standard_call() for SIOCSIWRATE, which calls cfg80211_wext_siwrate() in wext-compat.c. That builds a bitrate mask and calls rdev_set_bitrate_mask() which ends up in ieee80211_set_bitrate_mask() in cfg.c. The interface is marked running via SDATA_STATE_RUNNING but flags is 0, so check_sdata_in_driver() fails. When the interface is being torn down, or when wext ioctl is issued during interface bringup before drv_add_interface() sets IN_DRIVER, the running check passes while IN_DRIVER is clear. Check IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() before calling the driver, returning -ENETDOWN. This avoids the WARN_ONCE in driver-ops.h and matches other cfg.c operations that bail early when not in driver. This change should be safe because wiphy mutex is held in cfg80211_wext_siwrate() via guard(wiphy), and IN_DRIVER is set/cleared under RTNL and wiphy paths in drv_add_interface() and drv_remove_interface() in driver-ops.c, so the check is race-free against driver add/remove. Returning -ENETDOWN is the same error other not-running paths use and does not introduce new locking. Reported-by: syzbot+af177aa139efdd13a9da@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=af177aa139efdd13a9da Link: https://lore.kernel.org/all/6a75205c.59b6c763.2bba34.00c3.GAE@google.com/ Fixes: 554a43d5e77e ("mac80211: check sdata_running on ieee80211_set_bitrate_mask") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Link: https://patch.msgid.link/20260808104755.319c686e@fangorn Reported-by: syzbot+dcaca020ca8377e7ced0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dcaca020ca8377e7ced0 [also add second syzbot report] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 45cf7a0835202e929ed38bc74ea3f9196fca4b59 Author: Zhao Li Date: Tue Aug 25 19:25:23 2026 +0800 wifi: mwifiex: validate action frame fixed fields commit 1c25bfad93e69ce13f744a2fb919f02ea396a985 upstream. mwifiex_process_mgmt_packet() accepts an rx_pkt_length as small as a four-address struct ieee80211_hdr plus the two-byte firmware length prefix. After stripping the prefix, mwifiex_parse_mgmt_packet() can receive a frame equal to sizeof(struct ieee80211_hdr). For action frames, the parser reads the category byte immediately after that header and, for a public action frame, reads the following action code byte without verifying that either field is present. A truncated frame can therefore make the parser consume up to two bytes past the firmware-declared frame length. If those bytes look like a TDLS discovery response, the malformed frame can spuriously update peer signal state. Require the category and public action-code fields before reading them. Use sizeof(*ieee_hdr) so the checks and field accesses directly match the firmware four-address layout being parsed before address4 is removed. Suggested-by: Johannes Berg Suggested-by: Brian Norris Fixes: 72e5aa8d2a6d ("mwifiex: support for parsing TDLS discovery frames") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/66f148d83eb9f0970b9abbccc85d1b61244e54ad.camel@sipsolutions.net/ Link: https://lore.kernel.org/all/20260708195911.84365-8-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/20260723011013.76968-1-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/20260723202257.688-1-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/anuWyiPQja6_5vly@google.com/ Assisted-by: Codex:gpt-5 Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260825112523.95774-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 25217c5f6ce0bf3004f80c129464cd35fe9a420f Author: Pengpeng Hou Date: Sat Aug 15 21:52:27 2026 +0800 wifi: mwifiex: validate scan response extents commit 3687d7d48070838cc2953431b3a27717cab0aaf6 upstream. mwifiex_ret_802_11_scan() subtracts the fixed response fields and the firmware-provided BSS length from resp->size without first proving that either extent fits. A short response or oversized BSS length can therefore underflow tlv_buf_size and make the TLV parser walk beyond the command response. Compute the fixed extent from the selected normal or background scan response. Validate that the fixed fields and BSS data fit before deriving the TLV extent and entering the parser. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260815135227.50392-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 77e642af7f2f6029e12a35c847c56cbd0466e799 Author: Doruk Tan Ozturk Date: Fri Aug 14 15:47:04 2026 +0200 wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length commit e667aee1c192d67d27c803007bfa9c6e0873e959 upstream. mwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on element_id alone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 * 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing. Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large size_t and defeat the bound. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260814134704.85902-1-doruk@0sec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 162dbe1c285a621eab6a9f2851086b63a0378928 Author: Shengzhuo Wei Date: Mon Aug 31 02:42:13 2026 +0800 wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST commit d8efd84f49379ed28624098821f80e992657d935 upstream. The PDR_INTERFACE_LIST loop only checks that the record start is within the entry before reading an entire struct exp_if from it. A truncated trailing record makes the if_id/variant reads cross the entry boundary into the heap beyond the EEPROM buffer (verified with a KASAN reproducer of the loop). The variant also feeds the synth front-end selection, so this is not only a leak. Advance only while a full record still fits in the entry. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Acked-by: Christian Lamparter Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-2-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 81084c967c18233b19799a0c3352ebac043f31e2 Author: Shengzhuo Wei Date: Mon Aug 31 02:42:12 2026 +0800 wifi: p54: validate curve data length in the calibration curve converters commit ce858fa6b8a214dee5adb82358885fa024cdd887 upstream. p54_convert_rev0() and p54_convert_rev1() read calibration curve data from the device-supplied EEPROM entry using channel and points-per-channel counts taken verbatim from that same entry, so an entry that declares more data than it carries drives an out-of-bounds read past the EEPROM buffer (verified with a KASAN reproducer of the conversion loop). The sibling converters p54_convert_output_limits() and p54_convert_db() already validate their counts against the entry length; this path was missed. Reject the entry when the counts do not fit in the entry data. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-1-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3ddb88e237bc1e59fd37b1cf369f3b6c2dedae26 Author: Tianchu Chen Date: Fri Sep 4 13:39:34 2026 +0000 wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext() commit c1ba7f7f18465e259cf1b4d9c73fc73853d7f790 upstream. wilc_wlan_handle_isr_ext() takes the RX transfer size from the device-reported interrupt status register (a 15-bit field shifted left by 2, up to 131068 bytes) and reads that many bytes from the device into rx_buffer, which is only WILC_RX_BUFF_SIZE (96K) large. The wrap check only handles the current offset; the size itself is never compared against the buffer, so a bogus SDIO device can make the driver OOB-write rx_buffer by up to ~32K with data it controls. The oversized transfer also leaves rx_buffer_offset past the end of the buffer, after which the unsigned wrap check stops working and the overflow can repeat. Drop any transfer whose size exceeds the RX buffer, acknowledging the data interrupt and re-arming the RX engine so the bogus frame is discarded and reception can continue. This also restores the rx_buffer_offset <= WILC_RX_BUFF_SIZE invariant the wrap check relies on. This is not expected to change driver behavior in most cases: without this check, an oversized transfer would most likely corrupt neighboring kernel memory instead of completing anyway, and the drop path performs the same interrupt acknowledgment and RX engine re-arming as the normal path, so subsequent transfers are received unaffected. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/7c971924c6bdccf6c2f75704a5a746e9303aaf64@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e98ad9f4c59f2e836f8d971b57763a4277680422 Author: Ali Ahmet Memis Date: Fri Aug 7 11:52:30 2026 +0000 wifi: wilc1000: fix out-of-bounds read in P2P public action frames commit ba6cb7c0868a412c2eb68e8efd5aa38bfb258a14 upstream. wilc_wfi_p2p_rx() and mgmt_tx() start parsing a frame once ieee80211_is_public_action() returns true. That helper only verifies the frame is long enough for the action category field, that is offsetofend(struct ieee80211_mgmt, u.action.category), 25 bytes. Both functions then read the P2P public action header up to oui_subtype at offset 30 and pass "size - ie_offset" to cfg80211_find_vendor_ie(), where ie_offset is offsetof(struct ieee80211_mgmt, u) + sizeof(*d), i.e. 32. A public action frame of 25 to 31 bytes passes the check but is shorter than that 32 byte header, so oui_subtype can be read out of bounds, and because the length is unsigned, "size - ie_offset" underflows to a value close to 4 GiB. cfg80211_find_vendor_ie() takes an unsigned int length, so even the size_t subtraction in mgmt_tx() is truncated to the same value. It then walks far past the buffer searching for a vendor element until it reaches unmapped memory. In the receive path the frame arrives over the air and needs no association, so a nearby unauthenticated device can crash the host while it is in P2P listen. Reject frames shorter than the P2P public action header in both paths before dereferencing it. Fixes: 4fb8b5aa2a11 ("staging: wilc1000: refactor p2p action frames handling API's") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260807115230.136767-1-ali@iusegentoo.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 85ec6c451fe681ac3135dfa43a519f1404ae63ad Author: Runyu Xiao Date: Thu Aug 20 20:51:26 2026 +0800 wifi: wlcore: release runtime PM ref on regdomain config failure commit 8a1f3cf89ddcc700e25afe42cfad333059adcc94 upstream. wlcore_regdomain_config() gets a runtime PM reference before sending the regulatory-domain command. When wlcore_cmd_regdomain_config_locked() fails, the function queues recovery and returns without dropping that reference. Release the reference after handling the command result so both success and failure paths balance the preceding pm_runtime_resume_and_get(). The recovery worker takes a separate runtime PM reference and cannot release the reference held here. Fixes: fa2648a34e73 ("wlcore: Add support for runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260820125126.12757-1-runyu.xiao@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b79e2f6585c014c42384f4caa7a37b3e5d26179c Author: Tianchu Chen Date: Fri Sep 4 14:24:45 2026 +0000 wifi: rsi: fix heap OOB write on key removal commit e6c5ed7a98d7bc8b0f7918246f1c90ddb3f79dfa upstream. When a key is removed (data == NULL), rsi_hal_load_key() runs: memset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ); set_key is a struct rsi_set_key *, so the subscript is scaled by sizeof(struct rsi_set_key) (160 bytes): &set_key[FRAME_DESC_SZ] is skb->data + 2560, and the memset writes 144 zero bytes starting 2.4KB past the end of the 160-byte skb data buffer, corrupting unrelated heap objects. The intended byte offset would have been (u8 *)set_key + FRAME_DESC_SZ. The write fires on every DISABLE_KEY callback, so plain disconnects, roams and interface teardowns trigger it on real networks. The memset is redundant: the whole buffer is zeroed right after allocation, so the frame sent to the device is byte-identical without it. Drop the else branch; normal operation is unaffected. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/90bb2b07007942064c04aa3729cedd9eb1e930b1@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3fb3663260ec396f86b733aab9f81fac6669d2fa Author: Jiangshan Yi Date: Sat Aug 15 19:57:24 2026 +0800 wifi: libertas_tf: fix UAF in lbtf_free_adapter() commit bbb9a0ab96d44a64529aafc7a16de460a1712f6a upstream. lbtf_free_adapter() calls lbtf_free_cmd_buffer() to free the command buffers before calling timer_delete_sync() to wait for the command timer callback. If the timer callback (command_timer_fn) is already running when lbtf_free_cmd_buffer() frees the command array, the callback dereferences priv->cur_cmd->cmdbuf which points to freed memory. Swap the order so that timer_delete_sync() runs first, ensuring any in-flight callback has completed before the command buffers are freed. Fixes: 06b16ae53192 ("libertas_tf: main.c, data paths and mac80211 handlers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260815115724.920628-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 275d474a4b4bd4e73b18b1452f12e78806a8843a Author: Stanislaw Gruszka Date: Thu Aug 20 11:30:59 2026 +0200 wifi: iwlegacy: fix broadcast stations deallocation commit b5526b780f8b297a76030410b96ba29153afb98f upstream. On the error path of __il4965_up(), il_dealloc_bcast_stations() clears only IL_STA_UCODE_ACTIVE, leaving IL_STA_BCAST set. This causes the same broadcast stations to be deallocated again by __il4965_down(). This can occur when RF_KILL is toggled during driver startup. To fix clear the entire 'used' field, since we will not do any other operations on the station. Reported-and-tested-by: Martin-Éric Racine Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221733 Fixes: c2fd34469d16 ("iwl4965: Fix a memory leak in error handling code of __il4965_up") Cc: # 7.1.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Cc: # 6.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Cc: # 5.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260820093059.18779-1-stf_xl@wp.pl Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 10eeb0b29fd7f52487c9ae573e8d79c210a0095d Author: Jiangshan Yi Date: Sat Aug 15 20:10:43 2026 +0800 wifi: brcmsmac: fix UAF in brcms_free_timer() commit 1eeca1d5e0920fbdad6449768fd2d4364e714180 upstream. brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of(). Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260815121043.938414-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 960ae7149055b0f5c527c1768902b2d49f2ef92a Author: Wentao Liang Date: Wed Sep 16 17:05:11 2026 +0000 watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init() commit 88f113634028ca90a857031837d8061d1a9e1a7b upstream. sp5100_tco_init() stores the PCI device matched by for_each_pci_dev() in the global sp5100_tco_pci and keeps its reference for the lifetime of the driver, but neither sp5100_tco_exit() nor the error paths of sp5100_tco_init() call pci_dev_put(), leaking the reference on driver registration failure and on every module load/unload cycle. Drop the reference when the platform driver or device registration fails and when the module is unloaded. Fixes: 15e28bf13008 ("watchdog: Add support for sp5100 chipset TCO") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260916170511.2086199-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 72c504239a77e323ed33ff1cf1e6883c436eb9e2 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:49 2026 +0800 watchdog: digicolor: Avoid division by zero commit 400cb663ca019bae6eb878f06f1094ddf7c0b0df upstream. clk_get_rate() could return 0. Avoid a division by zero panic. Since get_timeleft() cannot propagate errors, check the clock rate early in probe() and cache the rate in the driver data as it is unlikely to change at runtime. Fixes: 336694a01dae ("watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Acked-by: Baruch Siach Link: https://patch.msgid.link/20260913064851.8239-2-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 722993f9a5fdfb65352f69db4faf13b21732695d Author: Guangshuo Li Date: Mon Sep 14 15:36:38 2026 +0800 hwmon: (w83793) release probe data through kref commit c702a5f18b780e477eccbbab558e590e9673e4cb upstream. w83793_probe() initializes data->kref to manage the lifetime of the driver data. The normal remove path drops the driver-owned reference with kref_put(), while watchdog users take and release additional references through the same kref. However, the probe error path still frees data directly with kfree(). This bypasses the kref-managed lifetime and discards the initial reference without a matching kref_put(), leaving the reference accounting unbalanced. Drop the probe-owned reference with kref_put() instead and let w83793_release_resources() perform the final free, matching the normal remove path. This issue was found by manual code inspection. Fixes: 5852f9609d21 ("hwmon: (w83793) Add watchdog functionality") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914073638.1662500-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 081e3a78453635fb370b1712809d2af29e60b4c5 Author: Guangshuo Li Date: Mon Sep 14 14:28:09 2026 +0800 hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove commit 0ff9c7775e51ac6d47b1bb5c46f06b1434fe58a8 upstream. When the fan/pwm 4-5 pins are not used as GPIO, w83791d_probe() creates the w83791d_group_fanpwm45 sysfs group on the I2C client device. The probe error path removes this group when a later initialization step fails, but the normal remove path only removes w83791d_group. As a result, the optional fan/pwm 4-5 sysfs files can remain after the driver is unbound. The callbacks associated with these files access the driver data, which is devm allocated and released after driver unbind. Leaving the sysfs files behind can therefore result in accesses to stale driver data. Remove w83791d_group_fanpwm45 during normal teardown as well. This issue was found by manual code inspection. Fixes: 6e1ecd9b8f13 ("hwmon: (w83791d) fan 4/5 pins can also be used for gpio") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914062809.1650538-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ed0905fda39682d3da7937184397d3276abbffa8 Author: Iván Ezequiel Rodriguez Date: Tue Sep 1 10:06:28 2026 -0300 Input: zero ff_effect before compat copy in input_ff_effect_from_user commit f84819ef8d66931ee3998fee3c4f03230f4cb6cc upstream. In the compat path input_ff_effect_from_user() aliases the caller's native struct ff_effect with the smaller struct ff_effect_compat and copies only the compat sized prefix: compat_effect = (struct ff_effect_compat *)effect; if (copy_from_user(compat_effect, buffer, sizeof(struct ff_effect_compat))) The tail of the native structure is never written. Callers pass an uninitialized on-stack object, for example evdev_do_ioctl() for EVIOCSFF, so those bytes keep their previous stack contents. input_ff_upload() then stores the full native structure in ff->effects[id], from where a uinput based force feedback daemon can read it back via UI_BEGIN_FF_UPLOAD, disclosing kernel stack memory to userspace. Zero the effect before the compat copy. Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20260901130629.24078-3-ivanrwcm25@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7a3d7c68aa36f68e2a4824da4782c0e5d7c4eba4 Author: Dmitry Torokhov Date: Wed Aug 5 22:44:23 2026 -0700 Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound commit fe10579b6dc3f0dac61e51e1797cacbba5039ac2 upstream. Transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmi_dev device. When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or rmi_enable_irq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabled_mutex. Fix this by checking if driver data is attached to rmi_dev in rmi_driver_suspend() and rmi_driver_resume(), exiting early if no driver data is present. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Reported-by: syzbot+09103639e39c989e3ed3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=09103639e39c989e3ed3 Cc: stable@vger.kernel.org Assisted-by: LLM Link: https://patch.msgid.link/anQe8UiyUR4x0flD@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 697b538406e7b0a98beea2d6008e351ca9bd51e5 Author: Raphaël Larocque Date: Thu Sep 10 12:44:25 2026 -0400 Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722) commit 26eb3d92c7a4d7adb1ae1740ca6e8e100b11d1ec upstream. The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a Synaptics touchpad whose SMBus companion is not ready at boot and takes roughly 200 seconds to appear. During this window the touchpad and TrackPoint are completely unresponsive on approximately 50% of boots, making the machine unusable until the companion finally registers. The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the kernel attempts to use SMBus/RMI4 mode by default. When the companion is not ready, psmouse_smbus_init() leaves breadcrumbs and returns -EAGAIN, the PS/2 fallback path is taken, but the device does not function properly until the companion appears and RMI4 takes over. Disable SMBus InterTouch for board id 2722 so the touchpad and TrackPoint work immediately via PS/2 from boot. Users can still force SMBus with psmouse.synaptics_intertouch=1 if needed. Tested-by: Raphaël Larocque Signed-off-by: Raphaël Larocque Link: https://patch.msgid.link/20260910164425.12832-1-rlarocque@disroot.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c3a94bfedfa2e4c4d37d1181e8db1ab010f1321a Author: Hans de Goede Date: Wed Sep 9 11:39:34 2026 +0200 Input: soc_button_array - check btns_desc->package.count commit fb5022278b6ea7f1838e3ef78028d5d5e3375f65 upstream. Check that btns_desc->package.count is not 0 before accessing btns_desc->package.elements[0]. Fixes: 4c3362f44980 ("Input: soc_button_array - add support for ACPI 6.0 Generic Button Device") Cc: stable@vger.kernel.org Reported-by: Shashiko Closes: https://lore.kernel.org/linux-input/20260909091440.3384C1F00A3A@smtp.kernel.org/ Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260909093934.29411-2-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 93b333a7234a720b6f726a7af059333b91a35c25 Author: Hans de Goede Date: Wed Sep 9 11:39:33 2026 +0200 Input: soc_button_array - fix MS Surface Pro 11 probe failure commit ed22ad5fdbdbf9b4cb4ad3003f60314b5a5eb89d upstream. On the MS Surface Pro 11 soc_button_array probing races with the GPIO driver probing. If soc_button_array wins the race then gpiod_get() returns EPROBE_DEFER, which should normally take care of retrying later, but the soc_button_array code deliberately ignores EPROBE_DEFER causing it to fail its probe() which causes the volume and power buttons to now work. The ignoring of EPROBE_DEFER is there to deal with a problem specific to older Bay Trail (BYT) and Cherry Trail (CHT) tablets which often use this driver. Modify the error handling to only ignore EPROBE_DEFER on BYT and CHT platforms and propagate EPROBE_DEFER normally on other platforms. Fixes: bcf059578980 ("Input: soc_button_array - partial revert of support for newer surface devices") Cc: stable@vger.kernel.org Reported-by: Sergey Lebedev Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/ Signed-off-by: Hans de Goede Tested-by: Sergey Lebedev Link: https://patch.msgid.link/20260909093934.29411-1-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d01337c0892d1509500c727edf81380777c2dd0f Author: Dmitry Torokhov Date: Tue Aug 4 22:08:54 2026 -0700 Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block() commit 51cfe54f815ae175c7d1126b983d4d7c89715004 upstream. When chunking writes into SMBus blocks in rmi_smb_write_block(), the loop calculates block_len using the original total length (len) instead of the remaining length (cur_len). If len is greater than 32 bytes (SMB_MAX_COUNT), block_len remains 32 for every iteration, even on the final partial chunk where fewer than 32 bytes remain. This causes smb_block_write() to read 32 bytes from the advanced data buffer pointer, reading past the end of the input buffer. Fix this by calculating block_len using cur_len and advancing the buffer and address pointers by block_len. Fixes: 82264d0cf7ae ("Input: synaptics-rmi4 - add SMBus support") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Assisted-by: LLM Link: https://patch.msgid.link/anLFSMKSoKyyZ272@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 092ae6d1f09434cb3f1caeea531a6f6d501ef242 Author: Chris Sommers Date: Mon Sep 7 11:27:23 2026 -0700 Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P commit 25e424eb4ae1a662d9c3573218d06ac32f797fc5 upstream. On the Acer Aspire Go 15 (AG15-42P), the internal keyboard drops out ~5 seconds after boot on both Linux and Linux-LTS kernels. Keystrokes on the built-in keyboard stop registering while the trackpad and external keyboards remain functional. Testing confirms that booting with the i8042.reset kernel parameter resolves the issue and keeps the internal keyboard responsive. Add SERIO_QUIRK_RESET_ALWAYS to i8042_dmi_quirk_table for the Acer Aspire AG15-42P to automatically apply this quirk on boot. Signed-off-by: Chris Sommers Link: https://patch.msgid.link/20260907182723.2709981-1-chris.sommers@icloud.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c0aebb57b73c7d06ad21731099afe119b113c403 Author: Iván Ezequiel Rodriguez Date: Tue Sep 1 10:06:27 2026 -0300 Input: evdev - zero absinfo before partial copy in EVIOCSABS commit 8b852965b8eaf910c314dc346967ed82c8d4f235 upstream. The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct input_absinfo: if (copy_from_user(&abs, p, min_t(size_t, size, sizeof(struct input_absinfo)))) The size comes from _IOC_SIZE() of the ioctl command and is therefore fully controlled by userspace. A short size leaves the trailing part of the structure holding whatever was on the kernel stack, and the whole structure is then stored into the device: dev->absinfo[t] = abs; EVIOCGABS hands that back to userspace, disclosing the stale stack bytes. Only the resolution field is currently cleared, which covers the legacy struct layout but not an arbitrarily short size. Zero the structure before the copy so any part not supplied by the caller reads back as zero. The existing resolution fixup is kept, since it also handles a size that partially overlaps that field. Fixes: 448cd1664a57 ("Input: evdev - rearrange ioctl handling") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20260901130629.24078-2-ivanrwcm25@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 03628268af0daef030ed5ba6924b55c62e1d22c9 Author: Alexei Turtanov <9alexei9@gmail.com> Date: Fri Aug 28 14:22:39 2026 +0300 Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026 commit aefbda23eeba234c3ff0f135dc5be6e294bd25a6 upstream. The internal keyboard of the Xiaomi Redmi Book Pro 16 2026 (board TM2425) does not work: atkbd_probe() succeeds and every command is ACKed, but no scancodes ever arrive afterwards. Testing on the hardware through serio_raw shows that ATKBD_CMD_RESET_DIS (0xF5) is the culprit. After 0xF5 the embedded controller keeps ACKing commands but stops delivering scancodes, and neither ATKBD_CMD_ENABLE (0xF4) nor ATKBD_CMD_RESET_BAT (0xFF) bring them back. Only re-enabling the keyboard interface at the controller level (i8042 command 0xAE, or rewriting the command byte as i8042_port_close() does) revives it. Running the init sequence without 0xF5 (0xED 0x00, 0xF3 0x00, 0xF4) keeps the keyboard working. 'i8042.dumbkbd=1' also works around this, but then the driver never writes to the keyboard and the LEDs cannot be controlled. Use the existing atkbd_deactivate_fixup quirk instead, as done for the sibling TM2424 by commit 3a046db33bb9 ("Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard"). Tested on v7.2: keyboard, Caps Lock LED and s2idle suspend/resume all work. DMI: XIAOMI REDMI Book Pro 16 2026/TM2425, BIOS RMAPT6B0P0909 05/22/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Cc: stable@vger.kernel.org Signed-off-by: Alexei Turtanov <9alexei9@gmail.com> Link: https://patch.msgid.link/20260828112239.18081-1-9alexei9@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 338ea34931455f599b128044498ff12e60d72ca7 Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:58 2026 +0200 mmc: sdhci_am654: Reset command and data lines on failed tuning commit 7197d9107d9545730153b82ea5a411c5208b443f upstream. The CMD/DATA reset after tuning should be performed regardless of whether tuning succeeded or failed, since tuning data may remain in the buffer in either case. Move the error return after the reset so that the controller is always cleaned up. Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7d2f0ec16b300645f20435a6c3827b15e01419af Author: Xu Rao Date: Tue Aug 18 19:31:53 2026 +0800 mmc: spi: reset bytes_xfered before retrying CRC failures commit 8b0cc8707f65e0f51912e764e1b309b2559db1ec upstream. mmc_spi_data_do() updates data->bytes_xfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytes_xfered may therefore contain the number of bytes completed before the failing block. mmc_spi_request() has a private recovery path for such CRC failures. It sends STOP_TRANSMISSION, clears data->error and jumps back to crc_recover to issue the same command and data request again. However, it does not clear data->bytes_xfered before the retry. If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytes_xfered. For a multi-block request this can make the completed request report more bytes than were transferred by the successful retry, and can even exceed the request size when most blocks completed before the CRC error. This is most likely to be observed on MMC-over-SPI systems where long multi-block transfers occasionally hit a data CRC error but the mmc_spi-internal retry succeeds. The data itself is retried, but the completion accounting is not. Clear data->bytes_xfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt. Fixes: 061c6c847eeb ("mmc_spi: Recover from CRC errors for r/w operation over SPI.") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cab22423366c4744d8c4401f9dcab371b11e7830 Author: Runyu Xiao Date: Wed Sep 2 22:09:26 2026 +0800 mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt commit d5ea0d226e8f0801d78702142a124d78c317d822 upstream. The threaded IRQ handler can run before devm_request_threaded_irq() returns, but thread_lock was initialized afterwards. Initialize it before requesting either interrupt. Fixes: 8047310ee984 ("mmc: sh_mmcif: fix a race, causing an Oops on SMP") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 9e992d59138fcfaa4bad7cc0750265b0a8bca100 Author: Felix Gu Date: Sat Aug 22 02:58:47 2026 +0800 mmc: sdio_uart: fix xmit_fifo leak when the port table is full commit 53823e25793a97d07e6e98e0904bbf74cac8bc76 upstream. sdio_uart_add_port() allocates the transmit fifo before claiming a slot in sdio_uart_table[]. When all UART_NR slots are taken, it returns -EBUSY with the fifo still allocated, but the probe error path only kfree()s the port, leaking the transmit fifo. Free the fifo in the failure path of sdio_uart_add_port() itself so the function retains nothing on error. Fixes: 8b197a5ce7a7 ("sdio_uart: Use kfifo instead of the messy circ stuff") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6b22b4d29e4fc1d2de2e4d7174925d68220165fb Author: Myeonghun Pak Date: Sun Sep 13 18:35:38 2026 -0400 mmc: sdhci-of-aspeed: Remove children before releasing SDC resources commit 4396d70bb7fec531bcf934fed016b2f3300c670b upstream. Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse order before disabling the parent clock on both paths. Use of_platform_device_destroy() because manual child creation does not set the flag required by of_platform_depopulate(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 740f595f8ad678cb4d79f13edd12851df2492bdd Author: Fan Wu Date: Fri Aug 7 03:26:54 2026 +0000 mmc: mxcmmc: cancel data work and watchdog on remove commit d3a421c82412344022982d5b91ba23194a0a6f29 upstream. mxcmci_remove() frees the host through the devm tail, but neither it nor mmc_remove_host() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(), is deleted only by the DMA- and IRQ-complete paths, which the remove path does not explicitly drain; it can therefore fire after the host is freed and dereference it in mxcmci_watchdog(). host->datawork, armed from the IRQ handler on the PIO path, is not cancelled by the remove path either. Free the devm-registered IRQ, then cancel datawork and delete the watchdog in mxcmci_remove(), before dma_release_channel(). Freeing the IRQ first keeps a trailing handler from re-arming datawork between the cancel and the host free. Both callbacks are non-self-rearming. This issue was found by an in-house static analysis tool. Fixes: f6ad0a481342 ("mmc: mxcmmc: fix bug that may block a data transfer forever") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e43847c4e70eba51a553c2e43d32f080d5849554 Author: Zhu Ling Date: Fri Sep 4 17:07:46 2026 +0800 mmc: core: Fix OF node reference leak on card add failure commit 08b54e16d547d5c1aa61bf7a3595bb1620975eeb upstream. mmc_of_find_child_device() returns a device node with its reference count incremented. mmc_add_card() stores the reference before calling device_add(), while the card is marked present only after device_add() succeeds. If device_add() fails, the callers release the card through mmc_remove_card(). However, mmc_remove_card() only drops the OF node reference for a present card, leaking the reference on this error path. Move of_node_put() outside the present-card conditional so the reference is released for both registered cards and card-add failures. Fixes: 25185f3f31c9 ("mmc: Add SDIO function devicetree subnode parsing") Cc: stable@vger.kernel.org Signed-off-by: Zhu Ling Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c781e737aa0de95289b1774d5fd29388895737a9 Author: Christian Göttsche Date: Thu Sep 3 13:43:38 2026 +0200 selinux: always fill AVC decision in avc_has_perm_noaudit() commit 8861db305103107199b1426f25fde1fb6d465583 upstream. avc_has_perm_noaudit() is documented to return a copy of the access decision in @avd, but its early return for an empty requested permission set leaves the buffer untouched. All callers pass an uninitialized stack variable and afterwards feed it to avc_audit(), and the inode hook even stores it in the per-task decision cache. Fill in a deny-all, audit-all decision, similar to avd_init(), so every caller receives a defined value at no cost on the hot path. Cc: stable@vger.kernel.org Fixes: e6f2f381e4015386 ("selinux: replace BUG_ONs with WARN_ONs in avc.c") Signed-off-by: Christian Göttsche Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 791471421d848ce13e84f4b21c9e19973d471c4e Author: Shuangpeng Bai Date: Sun Aug 16 00:45:10 2026 -0400 IB/mlx4: Fix use-after-free on pkey sysfs registration failure commit 1af874e9f4ce22ccf8b10ab5462f32c70d3be21a upstream. register_pkey_tree() ignores errors from register_one_pkey_tree() and continues registering the remaining slaves. The per-slave error path has already released the pkey parent kobjects, but their pointers remain stored in the device. A later device cleanup therefore passes the stale pointers to kobject_put(), causing a use-after-free. Clear the parent pointers after releasing a failed slave tree and skip unregistered trees during device cleanup. This preserves the existing best-effort registration behavior while preventing a second cleanup of the failed tree. Fixes: c1e7e466120b ("IB/mlx4: Add iov directory in sysfs under the ib device") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260816044510.3848996-1-shuangpeng.kernel@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 84c3d3852923c3817f459e77946f6b2a086db6e9 Author: Shengzhuo Wei Date: Thu Aug 27 23:43:02 2026 +0800 i2c: imx: release DMA channels on probe error commit e9f03b9625e2eeaca357b065c92d5b14064a1583 upstream. i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is optional: on errors other than -EPROBE_DEFER the driver falls back to PIO mode and probe continues. If i2c_add_numbered_adapter() then fails, probe returns through clk_notifier_unregister without releasing the channels, because the remove callback is not invoked after a failed probe. Release the channels on the probe error path, mirroring i2c_imx_remove(). Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Cc: # v3.19+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-2-271d4adc03a0@cherr.cc Signed-off-by: Greg Kroah-Hartman commit 2f432008e3af3ff6b24494c0cc835a685b9f282b Author: Shengzhuo Wei Date: Thu Aug 27 23:43:01 2026 +0800 i2c: at91: release DMA channels on remove and probe error commit f7eeb1af8537b05953fb1c88ab8b59d94059a381 upstream. at91_twi_configure_dma() requests exclusive tx/rx DMA channels, but nothing ever releases them on driver detach, and the probe error path after the channels are acquired (i2c_add_numbered_adapter() failure) returns without releasing them either, because the remove callback is not invoked after a failed probe. Move the release into a helper, call it from the existing configure-failure path, the adapter-registration failure path, and at91_twi_remove(). Fixes: 60937b2cdbf9 ("i2c: at91: add dma support") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Cc: # v3.8+ Acked-by: Mukesh Kumar Savaliya Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-1-271d4adc03a0@cherr.cc Signed-off-by: Greg Kroah-Hartman commit bfcc51339661d4d1b7c293ced6839de8d7c3b6d8 Author: Maoyi Xie Date: Fri Aug 21 17:59:35 2026 +0800 keys: translate request_key_auth pid for the reading procfs instance commit 0d6a4268b06084baafd8ee5d66955c7e1c2e053b upstream. request_key_auth_describe() prints rka->pid into /proc/keys as a raw pid_t in the initial pid namespace. A reader can open /proc/keys through a mount in another pid namespace. That reader sees a number with no meaning there. The number can even name an unrelated task. The line needs VIEW on the key. So the reader either shares the key owner's uid or possesses the key. The fix keeps a struct pid. Commit 4f82f45730c6 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t") gave /proc/net/ip6_flowlabel the same storage. The print goes through pid_nr_ns(). It renders against the pid namespace of the procfs instance the line is read through. Commit ad08978ab41c ("ipv6/flowlabel: simplify pid namespace lookup") moved that print to the same anchor. Output through an initial namespace /proc does not change. The line shows 0 for a requestor with no number in that namespace. Translating at read time was the alternative. find_pid_ns() can resolve a recycled number. The line would then name a live task with no connection to the key. A stored struct pid gives 0 instead when the requestor has no number there. Link: https://lore.kernel.org/keyrings/20260809110202.2180410-1-maoyixie.tju@gmail.com/ Fixes: 78b7280cce23 ("KEYS: Improve /proc/keys") Cc: stable@vger.kernel.org # v5.10+ Assisted-by: Claude:claude-opus-5 codeql Signed-off-by: Maoyi Xie Link: https://lore.kernel.org/r/20260821095935.1864998-1-maoyixie.tju@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 6008d8a756400b3e4a0aaddea08a2ee615712c7d Author: Mark Amirkan Date: Sun Sep 13 10:31:08 2026 +0000 net/packet: avoid truncating TPACKET_V3 private size commit 37213e61120297920ae4c937fcb326a360da5084 upstream. tpacket_req3.tp_sizeof_priv is an unsigned int, and packet_set_ring() validates the full value against the block size. init_prb_bdqc() then stores it in the unsigned short blk_sizeof_priv field. Commit 2b6867c2ce76 ("net/packet: fix overflow in check for priv area size") fixed the validation arithmetic, but an accepted value above USHRT_MAX still narrows when it is stored. For a 131072-byte block, tp_sizeof_priv=65536 is valid. The narrowing makes offset_to_first_pkt 48 instead of 65584, so packet records can be placed in the private area that userspace asked the kernel to preserve. blk_sizeof_priv is internal state, so widen it to hold the validated UAPI value. Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260913-b4-send-packet-private-v1-1-925eab2cd388@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bb10a0084c03a94364aeec542beddc5d49b59f59 Author: Mark Amirkan Date: Sun Sep 13 10:28:08 2026 +0000 net/packet: clear RX owner on VNET header error commit 33ff111d7ba3beb86e28938d6382bb5beabd865a upstream. Commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") added rx_owner_map and made tpacket_rcv() claim a V1 or V2 ring slot before converting the virtio-net header. If the conversion fails, the drop path leaves the slot claimed. With a one-frame TPACKET_V2 ring, an unsupported UDP GSO packet leaves the only slot unavailable, so the ring also drops the next valid packet. Clear the ownership bit on this error path. TPACKET_V3 already clears its block state here. Fixes: 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260913-b4-send-packet-vnet-v1-1-5545ffb528ae@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7adfd0a42174b85c6bd678858ecd6674f403f336 Author: Jamal Hadi Salim Date: Sat Sep 12 14:09:19 2026 -0400 net/sched: hhf: cap hh_flows_limit at change time commit 2cef2588c995722a901368def30befeef9ae55c6 upstream. hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths"), which bounded the quantum of the same qdisc; the hh_flows_limit bound is the remaining unbounded knob of that series' scope. Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048 instead of 500. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Cc: stable@vger.kernel.org Reported-by: Sashiko (gemini) Closes: https://sashiko.dev/#/patchset/20260822195509.112717-1-jhs@mojatatu.com Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-B855.v1.20260911153152@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b1a88633c36d2cbc3831382f3846754d344276fd Author: Zhiling Zou Date: Mon Aug 3 21:28:58 2026 +0800 ipv6: xfrm: use full sockets in local error paths commit 6973a21ee73c5567f883813c8ef414774b45892f upstream. xfrm6_local_rxpmtu() and xfrm6_local_error() dereference skb->sk as if it always pointed at a full IPv6 socket. That is not guaranteed. TCP SYN-ACK skbs can be owned by a TCP_NEW_SYN_RECV request_sock while the output path itself is driven by the full listener. If rerouting selects an IPv6 XFRM tunnel route with a lower MTU, the local PMTU/error handling path can reach these callbacks with that mini-socket still attached to the skb. The callbacks then miscast the request socket as a full inet/IPv6 socket and can read beyond the request_sock allocation when they access inet_sock or ipv6_pinfo state. Resolve the owner with skb_to_full_sk() in both callbacks and bail out when no full socket is attached. This matches the surrounding XFRM IPv6 PMTU/error logic, which already reasons about full sockets with skb_to_full_sk(). Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit b51ed7885ab0e8ecad765adc13b465cb1498cdc9 Author: Alexander Chesnokov Date: Wed Aug 12 08:34:26 2026 +0300 dmaengine: ti: k3-udma-glue: fix NULL dereference in k3_udma_glue_release_rx_chn() commit 0294b6dd515256c03ea2dbf508ddd3826d788579 upstream. If devm_kcalloc() for rx_chn->flows fails in a channel request function, the error path calls k3_udma_glue_release_rx_chn(), which dereferences the NULL rx_chn->flows pointer in k3_udma_glue_release_rx_flow(). Skip the flow release loop in k3_udma_glue_release_rx_chn() when rx_chn->flows is not allocated. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users") Cc: stable@vger.kernel.org Reported-by: Pavel Zhigulin Signed-off-by: Alexander Chesnokov Reviewed-by: Frank Li Link: https://patch.msgid.link/20260812053426.3521589-1-Alexander.Chesnokov@kaspersky.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit f953ecb0939fba930a76495f644d5968a6805797 Author: Christian Lugnberg Date: Mon Aug 17 15:51:23 2026 +0200 dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status commit 9096bdc8d930147f7c39a493a859acbd3a8485d8 upstream. sun6i_dma_tx_status() calls vchan_find_desc() to look up the virtual descriptor for a given cookie, before checking whether the pointer vd is NULL: vd = vchan_find_desc(&vchan->vc, cookie); txd = to_sun6i_desc(&vd->tx); /* vd may be NULL here */ if (vd) { for (lli = txd->v_lli; ...) vchan_find_desc() returns NULL when the descriptor has already been completed or is in-flight on a physical channel and no longer present in the virtual channel's descriptor list. When vd is NULL, to_sun6i_desc() is called unconditionally on &vd->tx before the NULL check, which is undefined behaviour. Move the call inside the if (vd) guard to ensure it is only reached with a valid pointer. vd = vchan_find_desc(&vchan->vc, cookie); if (vd) { struct sun6i_desc *txd = to_sun6i_desc(&vd->tx); for (lli = txd->v_lli; ...) Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg Reviewed-by: Frank Li Link: https://patch.msgid.link/20260817135723.12807-3-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit d3af08c305c10999cca767ab7ce920356104e7df Author: Christian Lugnberg Date: Mon Aug 17 15:51:22 2026 +0200 dmaengine: sun6i: fix non-atomic read of DMA position registers commit c90b6973daa37f4c283342dff881ae001dea4fe6 upstream. sun6i_get_chan_size() reads DMA_CHAN_LLI_ADDR and DMA_CHAN_CUR_CNT in two separate readl() calls with no synchronisation between them: pos = readl(pchan->base + DMA_CHAN_LLI_ADDR); bytes = readl(pchan->base + DMA_CHAN_CUR_CNT); DMA_CHAN_LLI_ADDR holds the physical address of the *next* descriptor the engine will load once the current one completes. DMA_CHAN_CUR_CNT holds the remaining byte count for the *current* descriptor. If the DMA engine advances to the next LLI entry between the two reads, pos becomes stale: it still points to what was the next descriptor at the time of the first read, but that descriptor is now the current one and CUR_CNT reflects its initial (full) byte count. The subsequent virtual-chain walk starts one entry too early and accumulates an extra full period's worth of bytes into the residue estimate. Fix this by re-reading DMA_CHAN_LLI_ADDR after DMA_CHAN_CUR_CNT and retrying if the value changed. This double-read pattern guarantees that both registers were sampled during the same descriptor interval. The cost is at most one extra readl() pair per call in the racy case, which occurs only at descriptor boundaries (~every 2 ms) and is negligible. Fixes: a90e173f3faf ("dmaengine: sun6i: Add cyclic capability") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg Reviewed-by: Frank Li Link: https://patch.msgid.link/20260817135723.12807-2-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit ae5d2a58b1928cefbcd2b60c39402b89ce2edf4c Author: Nicolas Thibert Date: Tue Sep 8 10:01:08 2026 +0200 Bluetooth: btusb: fix NXP IW610 composite device handling commit 2b50adefed9808a56d84d1de803cad882cc787fa upstream. The NXP IW610 module exposes itself as a composite USB device (0471:0215) with three interfaces: two real Bluetooth HCI interfaces (class 0xe0) and one vendor-specific WiFi interface (class 0xff) used by mwifiex-nxp. The composite device's whole USB descriptor reports class 0xe0/01/01 (Bluetooth), so btusb_table's generic USB_DEVICE_INFO(0xe0, 0x01, 0x01) entry matches every interface, not just the two real HCI ones -- btusb ends up binding the WiFi interface too, and mwifiex-nxp never gets it. Fix: 1. In btusb_table (the table the USB core actually matches against), explicitly ignore the WiFi interface via BTUSB_IGNORE, ahead of the generic entry. 2. In quirks_table, scope the existing BTUSB_MARVELL entry to the BT interface class instead of matching the whole device by VID/PID (harmless either way since quirks_table isn't consulted for initial binding, but keep it correct). Not upstream anywhere: checked NXP's own i.MX kernel fork (nxp-imx/linux-imx), no IW610 references in btusb.c on any branch -- their reference designs wire this chip differently (WiFi over SDIO per their release notes), so they never hit this. Signed-off-by: Nicolas Thibert Cc: stable@vger.kernel.org Assisted-by: LLM (Claude Sonnet 5, Anthropic) Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1f8645b7686d6cadc50b7b93b0ab2f94a677db09 Author: Mark Rutland Date: Tue Sep 8 16:17:22 2026 +0100 arm64: percpu: Fix this_cpu_and() mask generation commit 44274c657256b4911de82f8104e9e22f054cf742 upstream. The arm64 implementation of this_cpu_and(pcp, val) is built in terms of ANDNOT operations, which requires the 'val' argument to be bitwise negated. The bitwise negation is not implemented correctly, with two bugs described below. (1) The bitwise negation is performed as '~val' rather than '~(val)'. This won't always generate the expected value when 'val' is an expression. For example, for this_cpu_and(pcp, 1 - 1): * 'val' is '1 - 1' ===> (int) 0x00000000 * '~val' is '~1 - 1' ===> (int) 0xfffffffd * '~(val)' is '~(1 - 1)' ===> (int) 0xffffffff ... and thus bit[1] of 'pcp' would be preserved unexpectedly by the ANDNOT operation. (2) The bitwise negation is performed on 'val' before it has been cast to (at least) the width of 'pcp'. This won't always generate the expected value for the upper bits. For example, for this_cpu_and(pcp, zero), where 'pcp' is a u64 and 'zero' is a u32: * 'zero' ===> (u32) 0x00000000 * '~(zero)' ===> (u32) 0xffffffff * '(u64)~(zero)' ===> (u64) 0x00000000ffffffff * '~((u64)(zero))' ===> (u64) 0xffffffffffffffff ... and thus bits[63:32] of 'pcp' would be preserved unexpectedly by the ANDNOT operation. Fix these issues by adding brackets around 'val', and by casting 'val' to an appropriately-sized type before bitwise negation. Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Signed-off-by: Mark Rutland Reviewed-by: Jinjie Ruan Tested-by: Muhammad Usama Anjum Acked-by: Christopher Lameter (Ampere) Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit e44b8afed62fe980be8e1583bbf0012857889a76 Author: Mark Rutland Date: Tue Sep 8 16:17:21 2026 +0100 arm64: percpu: Fix this_cpu_write() casting commit 885bff055a0f251a51a0d4fd4f0a7b525582a3de upstream. The arm64 implementation of this_cpu_write() casts 'val' to unsigned long. This is necessary to handle cases where 'val' is a pointer type, and to avoid spurious compiler warnings for the (unreachable!) cases where the pointer type would be cast to a smaller integer type. Unfortunately, the cast is applied to 'val' rather than '(val)', which won't always generate the expected value when 'val' is an expression. For example, for this_cpu_write(pcp, zero - 1), where 'pcp' is a u64 and 'zero' is a u32: * 'zero' ===> (u32) 0x00000000 * 'zero - 1' ===> (u32) 0xffffffff * '(unsigned long)zero - 1' ===> (u64) 0xffffffffffffffff * '(unsigned long)(zero - 1)' ===> (u64) 0x00000000ffffffff Fix this by adding brackets around 'val'. Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Reported-by: David Laight Signed-off-by: Mark Rutland Reviewed-by: David Laight Reviewed-by: Jinjie Ruan Tested-by: Muhammad Usama Anjum Acked-by: Christopher Lameter (Ampere) Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d37a5b87577c4b4c1a1dcb000a9dff1df2cf886b Author: Wyatt Feng Date: Sat Aug 29 23:44:32 2026 +0800 net: xfrm: reject unrepresentable espintcp transport headers commit 96f01b53c2d05e003b040892256de54a586e8529 upstream. ESP-in-TCP can hand xfrm packets whose transport header offset no longer fits after the stream parser trims the TCP envelope. The plain transport header reset truncates that offset and triggers the skb warning path. Use the careful transport-header helper and drop the skb through the existing XFRM error path when the offset cannot be represented. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 4371d79ea74407fb992c985b1f94391e35bb8289 Author: Zhiling Zou Date: Sat Sep 12 21:22:43 2026 +0800 openvswitch: avoid reallocating confirmed conntrack labels commit 3f118c8217c109fd13ca61caa301d72c483897ef upstream. ovs_ct_get_conn_labels() adds the labels extension when a conntrack entry does not have one. Confirmed conntracks can be read locklessly, so adding an extension may reallocate and free the extension block while another CPU accesses it. Only add the extension for unconfirmed conntracks. A confirmed conntrack without labels now fails the caller's label operation instead of reallocating its extension storage. Fixes: c2ac66735870 ("openvswitch: Allow matching on conntrack label") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/372fbb062b40ae6723684f55484be86ff0064f8e.1789218015.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52c13c63bb3662c108244e7447055e30bf40244e Author: Jeffin Philip Date: Fri Sep 4 18:44:37 2026 +0530 RDMA/core: fix refcount bug in iwpm_get_nlmsg_request() commit 33fb59da49c4c3f5c2ec9f9d4447a56857a02c02 upstream. iwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail() making it accessible to global list where another CPU can kref_get() on nlmsg_request causing a refcount "addition on 0" bug. Fix this by initializing kref _before_ list_add_tail() so refcount for nlmsg_request can be incremented/decremented normally. In addition, also initialize every field before list_add_tail(). Reported-by: syzbot+bd317784d628820741b5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bd317784d628820741b5 Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260904131437.12917-1-jeffinphilip14@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 29b9ed83d8bfab5c6e11fcbf1aa836aa4ae26cb9 Author: Quanye Yang Date: Mon Aug 31 20:30:58 2026 +0800 RDMA/ucma: Serialize join and leave on copy_to_user failure commit 662ade4de9ff5eceb0820a9f8e9fac70ba6a815b upstream. rdma_join_multicast() queues RoCE work that later reads the ucma_multicast through event->param.ud.private_data, then list_add()s the CMA multicast at the head of id_priv->mc_list. rdma_leave_multicast() matches only by sockaddr and destroys the first hit. ucma_process_join() used to drop ctx->mutex after a successful join and retake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucma_multicast that the first thread frees. Keep ctx->mutex held from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mc_list, and a leave-by-addr would destroy an earlier successful join. Reported-by: syzbot+a6ffe86390c8a6afc818@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a6ffe86390c8a6afc818 Fixes: fe454dc31e84 ("RDMA/ucma: Fix use-after-free bug in ucma_create_uevent") Cc: stable@vger.kernel.org Signed-off-by: Quanye Yang Link: https://patch.msgid.link/20260831-rdma-ucma-mc-uaf-v1-1-b8eeb7046aff@proton.me Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 07cacab90290f795bad2e566790f4ba8e84cdf5f Author: Inbal Schussheim Date: Mon Sep 14 12:04:07 2026 +0300 tcp: exclude old ACKs from tcp fast path commit f81e6c3fb06327bc49cdd6e559845293ba06a704 upstream. Exclude old ACKs before SND.UNA from the tcp fast path as well as ACKs after SND.NXT. Such ACKs will fall through to the slow path, where tcp_ack() performs the appropriate validation and challenge ACK handling according to RFC5961 and Commit 3d501dd326fb1c7 ("tcp: do not accept ACK of bytes we never sent"). This prevents old ACKs from being accepted or modifying connection state as part of the fast path before appropriate ACK validation is applied. In particular, this prevents payload carried by a segment with an excessively old ACK from advancing RCV.NXT before the ACK is rejected. Fixes: 31770e34e43d ("tcp: Revert "tcp: remove header prediction"") Reported-by: Amit Klein Reported-by: Tamir Shahar Reported-by: Inbal Schussheim Suggested-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Inbal Schussheim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914090408.1435080-2-inbal.lipshtat@mail.huji.ac.il Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 424019be3f637da76b74f44a40034669acbb166f Author: Aohan Mei Date: Fri Sep 11 15:34:32 2026 +0800 rds: ib: use rds_conn_drop() on protocol version mismatch commit f97d8c7bab7843631206a114986c9059da03efeb upstream. rds_ib_cm_connect_complete() runs from the RDMA-CM event handler with conn->c_cm_lock held. When the peer negotiates a protocol version older than RDS_PROTOCOL_COMPAT_VERSION, the handler calls rds_conn_destroy(), which is only safe in the rmmod path: it synchronously tears the connection down and flush_work()es the shutdown work cp_down_w. That shutdown work (rds_conn_shutdown()) needs cp_cm_lock, which is the very lock the event handler still holds, so the flush never completes: the two workers wait on each other and the RDS connection workqueues stall for good. All other RDMA-CM failure paths (REJECTED, CONNECT_ERROR, DISCONNECTED) use rds_conn_drop(), which marks the connection RDS_CONN_ERROR and schedules the shutdown work asynchronously. Use it here as well. Fixes: f147dd9ecabf ("RDS/IB: Disallow connections less than RDS 3.1") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Reviewed-by: Allison Henderson Signed-off-by: Aohan Mei Link: https://patch.msgid.link/20260911073436.3542080-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0191c9ff23ef1678dbfb5ad253a2dee92feb5d71 Author: Niklas Cassel Date: Fri Sep 4 15:43:11 2026 +0200 ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY commit 82e47533221d4746947b74d2e79a478c36c6433a upstream. A user reported that commit 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") made the JMicron JMB585 unusable on his board. The failure is seen as soon as the ahci driver is probed, and booting with iommu=off does not solve the problem. Looking at the AHCI specification, PxCLBU and PxFBU are both read only '0' for HBAs that do not support 64-bit addressing. For HBAs that do support 64-bit addressing, the registers are read write, with a reset value that is Implementation Specific. When using the AHCI_HFLAG_32BIT_ONLY flag, the HBA does support 64-bit addressing, and a 32-bit DMA mask is set by simply clearing HOST_CAP_64. Thus, in this case, we need to explicitly clear the registers to 0. Fixes: 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") Fixes: c7a42156d99b ("ahci: disable 64bit dma on sb600") Cc: stable@vger.kernel.org Reported-by: Roland Waltersson Closes: https://lore.kernel.org/linux-ide/IA0PR17MB668730A4ECCD65F7A1DC3EDC9EB62@IA0PR17MB6687.namprd17.prod.outlook.com/ Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260904134310.1465051-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 764d0c9d77fc197f286716310c9e1a67a1032da1 Author: Jeremy Nyberg Date: Sun Sep 13 17:43:02 2026 -0700 Input: xpad - fix PDP Marvel Xbox 360 controller commit 7bc369cb3d3f3656eb77285628ee264264d28ad4 upstream. The PDP Marvel Xbox 360 controller with USB ID 0e6f:0147 is incorrectly classified as an Xbox One controller. With the current XTYPE_XBOXONE classification, the controller is detected but produces no input, while its four player LEDs continue blinking indefinitely. Classify USB ID 0e6f:0147 as an Xbox 360 controller instead. Tested on a PDP Marvel Xbox 360 controller with USB ID 0e6f:0147. All inputs register correctly and the player LED indicates the current player. Fixes: c225370e01b8 ("Input: xpad - sync supported devices with 360Controller") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Nyberg Link: https://patch.msgid.link/20260910071627.236014-1-SlickStretch3.0@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 785b6428b3df00e5e3f1cda9b4b8ace7ec3b3ca8 Author: Erich Sartison Date: Thu Sep 3 12:31:37 2026 +0200 Input: xpad - add support for Victrix Pro BFG Controller commit 971fa7ea8621e123feb9c8d7dc61be1c656bd945 upstream. The controller doesn't currently work via USB-cable. Signed-off-by: Erich Sartison Link: https://patch.msgid.link/20260903103137.630170-1-byt.es@mailbox.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8fb035232b505ab12119adf78f5fc1f93f2b7e24 Author: hackyzh002 Date: Wed Apr 19 20:22:33 2023 +0800 drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 commit 87c2213e85bd81e4a9a4d0880c256568794ae388 upstream. The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later. Reviewed-by: Christian König Signed-off-by: hackyzh002 Signed-off-by: Alex Deucher Signed-off-by: Roman Demidov Signed-off-by: Greg Kroah-Hartman commit 2a0fa56e29a44d9c3123e5227149bfb3bcf58079 Author: hpp.iscas Date: Sat Sep 5 21:40:04 2026 +0800 Input: eeti_ts - publish the OF module alias [ Upstream commit a52ae68a937efc353251aec27fc995ff66cbe1ca ] The EETI driver matches eeti,exc3000-i2c Device Tree clients, but only publishes the legacy eeti_ts I2C ID. The I2C core emits an OF modalias for a Device Tree client. Publish the existing OF match table within its CONFIG_OF guard. Fixes: e32d7f1b246c ("Input: eeti - add device tree matching table") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905134004.66336-1-hppiscas@163.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 5cefdb7acfc646fbded59ae77dfe0aac4c9e4a3c Author: Dmitriy Okunev Date: Mon Sep 14 12:15:57 2026 +0300 net: mvpp2: prevent buffer overflow in page_pool allocation [ Upstream commit 14cb1e7702e5cb3c58888f6aed498381a73927d2 ] The per‑processor buffering scheme is supported only if the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8). This is already checked in mvpp2_probe() during the initial activation of percpu_pools. However, mvpp2_change_mtu() may later call mvpp2_bm_switch_buffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->page_pool array in mvpp2_bm_init(). The array is sized to hold MVPP2_PORT_MAX_RXQ entries, and mvpp2_get_nrxqs() may return exactly that value. The per-CPU scheme then doubles it to nrxqs * 2, exceeding the array bounds. Check that the hardware version is MVPP22 or newer and that the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS before switching to per-CPU mode. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7d04b0b13b11 ("mvpp2: percpu buffers") Signed-off-by: Dmitriy Okunev Link: https://patch.msgid.link/20260914091557.71769-1-dokunevdmitriy@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1163cc82dcbc145f912bf2106ab668762f53e483 Author: Linus Walleij Date: Mon Sep 14 23:26:41 2026 +0200 net: ethernet: cortina: Ack RX overrun interrupt correctly [ Upstream commit 1dd85662fee6e2ac580b1c4f9a0c0a7ae6e31f0e ] The RX overrun interrupt is reported in interrupt status register 4, but gmac_irq() acknowledges it using the RX descriptor error bit from status register 0. For GMAC0 this writes the GMAC1 overrun bit, while for GMAC1 the shift leaves no bit in the 32-bit register. Acknowledge the same per-port RX overrun bit that was detected. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260914-b4-gemini-ethernet-fixes-2-v2-1-5ab39a047b90@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18899e2e4023369a8f7739c2255a59a9748d8d17 Author: Eric Dumazet Date: Tue Sep 15 04:30:54 2026 +0000 net: lock the socket in sock_gettstamp() [ Upstream commit 9ed55f3dbef4f4adfe65eb03b0c35c53229a8490 ] sk->sk_flags must only be changed while holding the socket lock, because sock_set_flag() and sock_reset_flag() use non atomic operations (__set_bit() and __clear_bit()). sock_gettstamp() is one of the last places where a bit of sk->sk_flags is changed from a syscall without owning the socket lock, through sock_enable_timestamp(sk, SOCK_TIMESTAMP). sk_set_memalloc() and sk_clear_memalloc() also change sk->sk_flags without the socket lock, but their callers (nbd, iscsi_tcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch. Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNS_NEW ioctl racing with bind() can cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set, because both threads perform a read-modify-write on the same word. CPU 0 (bind) CPU 1 (SIOCGSTAMPNS_NEW) -------------------------------- ---------------------------- read sk_flags = F read sk_flags = F compute F | BIT(SOCK_RCU_FREE) compute F | BIT(SOCK_TIMESTAMP) store F | BIT(SOCK_RCU_FREE) sk_add_node_rcu(sk, ...) store F | BIT(SOCK_TIMESTAMP) After the lost update, SOCK_RCU_FREE is clear while the socket is visible to lockless UDP receive lookups. sk_destruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it: BUG: KASAN: slab-use-after-free in ipv4_pktinfo_prepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4_pktinfo_prepare+0x30/0x410 udp_queue_rcv_one_skb+0x51c/0x1180 udp_unicast_rcv_skb+0x109/0x350 ip_protocol_deliver_rcu+0x14b/0x310 ip_local_deliver_finish+0x29d/0x390 ip_local_deliver+0x24d/0x2a0 Only grab the socket lock when SOCK_TIMESTAMP has to be set, to keep the common case lockless. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Jungwoo Lee Reported-by: Wongi Lee Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915043055.3441600-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 81ce5aca8a1d8232596160cc6feaa211b14a6db1 Author: Yige Jiang Date: Sun Sep 13 14:41:02 2026 +0800 net: netsec: fix device_node reference leak on phy_np [ Upstream commit 5ae916fabca141b79b32e2e57f3c915c0f1e1b2e ] netsec_of_probe() takes a reference on the PHY device_node with of_parse_phandle() and stores it in priv->phy_np, but the driver never drops it. One device_node reference is leaked per probe, on the success path as well as on every error path reached after netsec_of_probe(). Neither consumer takes ownership. of_mdio_parse_addr() is a static inline taking a const struct device_node * that only reads the "reg" property. of_phy_connect() borrows as well: of_phy_get_and_connect() in drivers/net/mdio/of_mdio.c brackets its own call with of_node_get() at :364 and of_node_put() at :373, which would be a double put if of_phy_connect() consumed the reference. The node is still in use at netsec_netdev_open() time, where it is passed to of_phy_connect(), so it has device lifetime. Release it at the probe error label, which every failure path after the acquire funnels through, and in netsec_remove(). Both releases precede free_netdev(), since priv is netdev_priv(ndev). The ACPI probe path leaves priv->phy_np NULL and of_node_put(NULL) is a no-op. There is no end-user visible symptom on currently supported platforms: a device_node is only freed once OF_DYNAMIC is enabled and the node has been detached, so on a static device tree the imbalance is inert. It is observable as a refcount that grows across bind/unbind cycles, and would matter under device tree overlays. Found by static analysis of reference acquire/release pairing rather than from a runtime report. No reproducer was produced and the change has not been runtime tested; it is compile-tested only (arm64, CONFIG_SNI_NETSEC=m via COMPILE_TEST). Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Yige Jiang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260913064102.37452-1-yigejiang86@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 06e9ae4310f1bebf7a1bca60867968f6cfda78b6 Author: Sasha Levin Date: Sun Sep 13 13:31:32 2026 -0400 ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments [ Upstream commit 11fc0048a6930f4fca44fe3bd16a0023e78846a2 ] arm allmodconfig fails to build with gcc: In file included from sound/soc/ux500/ux500_msp_i2s.c:20: sound/soc/ux500/ux500_msp_i2s.h:151:38: error: suggest parentheses around arithmetic in operand of '^' [-Werror=parentheses] sound/soc/ux500/ux500_msp_i2s.c:204:21: note: in expansion of macro 'MSP_TX_CLKPOL_BIT' cc1: all warnings being treated as errors The macros never parenthesized their argument: #define MSP_TX_CLKPOL_BIT(n) ((n & TCKPOL_MASK) << TCKPOL_SHIFT) That went unnoticed while every caller passed a plain variable, but configure_protocol() now passes an XOR expression, which binds as "a ^ (b & MASK)" rather than "(a ^ b) & MASK", and gcc rightly complains. No functional change: tx_clk_pol and rx_clk_pol only ever hold MSP_FALLING_EDGE (0) or MSP_RISING_EDGE (1), and bclk_inverted is a bool, so masking before or after the XOR gives the same 0/1 result. Parenthesize the argument anyway - it fixes the build and stops the macros from silently mis-evaluating a future composite argument. Fixes: 9ccbacf5a012 ("ASoC: ux500: Validate MSP DAI configuration") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609051547.G9SJp8UQ-lkp@intel.com/ Assisted-by: LLM Signed-off-by: Sasha Levin Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260913173132.1172003-1-sashal@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 98d8dcc4ebd10523507d4478e148809a7771a213 Author: Shivaprasad G Bhat Date: Tue Sep 15 22:04:17 2026 +0530 powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba [ Upstream commit 0b271f7d7f5ed45bc498a03ce0aa9cfd8402fc71 ] The commit b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") unified IOBA parameter checking across KVM and VFIO into iommu_tce_check_ioba(). While doing so, the passed in argument npages is ignored and constant value '1' is used leaving out a possible overflow as the callers can legitimately be using npages > 1 for H_STUFF_TCE or H_PUT_TCE_INDIRECT cases. Fix this by accounting for 'npages', checking for arithmetic overflow, and verifying that the entire requested range (ioba - offset + npages) does not exceed the table capacity 'size'. Fixes: b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Shivaprasad G Bhat Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Signed-off-by: Sasha Levin commit ed2f2ff63cb7e71204096e765c6d02c3b6974b95 Author: Amit Machhiwal Date: Tue Sep 15 22:04:16 2026 +0530 KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure [ Upstream commit 0a416ee20bcccddf91ca5b63696a23b9d11d73aa ] In kvmppc_svm_page_in(), if uv_page_in() fails after kvmppc_uvmem_get_page() has succeeded, the secure device page is never released. kvmppc_uvmem_get_page() sets a bit in kvmppc_uvmem_bitmap, allocates a kvmppc_uvmem_page_pvt struct, marks the GFN as KVMPPC_GFN_UVMEM_PFN, and calls zone_device_page_init() which sets refcount=1 and locks the page. The subsequent goto out_finalize skips the *mig.dst assignment, so migrate_vma_finalize() is a no-op for the page, and none of those resources are ever reclaimed. Each occurrence permanently consumes one entry from the firmware-bounded secure memory pool (kvmppc_uvmem_bitmap), leaks pvt, and leaves the GFN marked as secure — making it unusable for the lifetime of the VM. The twin __kvmppc_svm_page_out() already handles the analogous uv_page_out() failure correctly with unlock_page(dpage); __free_page(dpage). Apply the same pattern here: unlock_page() followed by put_page(), which chains through free_zone_device_folio() into kvmppc_uvmem_folio_free() to clear the bitmap bit, free pvt, and reset the GFN state. Reachable whenever uv_page_in() returns an error (e.g. UV pool exhaustion) on any POWER9/10 + Ultravisor/PEF system. Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Amit Machhiwal Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Signed-off-by: Sasha Levin commit caf09c09e0f323015ab6777ed1bad5aa10688631 Author: Eric Dumazet Date: Thu Sep 10 20:46:12 2026 +0000 drop_monitor: fix out-of-bounds write in reset_per_cpu_data() [ Upstream commit 439f392084f8f7f59ab9d47a9579185accefe1d8 ] In reset_per_cpu_data(), al is computed as: al = sizeof(struct net_dm_alert_msg); al += dm_hit_limit * sizeof(struct net_dm_drop_point); al += sizeof(struct nlattr); skb = genlmsg_new(al, GFP_KERNEL); ... nla = nla_reserve(skb, NLA_UNSPEC, sizeof(struct net_dm_alert_msg)); ... msg = nla_data(nla); memset(msg, 0, al); Because al includes sizeof(struct nlattr) (the 4-byte attribute header), genlmsg_new() allocates al bytes of tailroom starting at nla. However, msg points to nla_data(nla), which is located sizeof(struct nlattr) bytes past nla. Calling memset(msg, 0, al) therefore writes al bytes starting from msg, exceeding the allocated buffer by sizeof(struct nlattr) (4 bytes) and corrupting skb_shared_info. Fix this by letting al represent only the payload length, allocating the skb with genlmsg_new(nla_total_size(al), GFP_KERNEL), and zeroing al bytes from msg. Fixes: 683703a26e46 ("drop_monitor: Update netlink protocol to include netlink attribute header in alert message") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260910204612.3762015-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e7bf8f20e291ddb87466b068806cf1d2f567db7e Author: Eric Dumazet Date: Thu Sep 10 20:46:09 2026 +0000 drop_monitor: synchronize tracepoint unregistration on error path [ Upstream commit 6a038ef2b57922b6d9ca98ddac0df0681849b704 ] If register_trace_napi_poll() fails in net_dm_trace_on_set(), unregister_trace_kfree_skb() is called to roll back the kfree_skb tracepoint registration. However, tracepoint_synchronize_unregister() is omitted before calling cancel_work_sync() and module_put(). An in-flight probe executing concurrently on another CPU could call schedule_work() after cancel_work_sync() has already returned, leaving a pending work item scheduled after the module reference is dropped. If the module is then unloaded, executing the work item triggers a kernel panic. Add tracepoint_synchronize_unregister() after unregister_trace_kfree_skb() in the error path, matching net_dm_trace_off_set() and net_dm_hw_probe_unregister(). Fixes: 7c747838a558 ("drop_monitor: Split tracing enable / disable to different functions") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260910204612.3762015-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba61f60ca0458777ceaa2900277aef01741f7f67 Author: Tzung-Bi Shih Date: Mon Sep 14 09:47:29 2026 +0000 Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown [ Upstream commit 7b60ee5f46f2ee329de661f7c68b6818d8136220 ] In btmtksdio_shutdown(), pm_runtime_get_sync() is called at the beginning of the function. However, if sending the WMT function control command fails later, the driver returns early. It bypasses the corresponding pm_runtime_put_noidle() and pm_runtime_disable() calls, leaking the PM usage counter and leaving PM runtime enabled indefinitely. Fall through to execute the PM runtime cleanup block even if WMT errors. Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Signed-off-by: Tzung-Bi Shih Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f448a5f5bd10d792440a1b08cf2e8f311767032d Author: Baineng Shou Date: Thu Sep 10 10:16:52 2026 +0800 dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg() [ Upstream commit 075bc7b1d3dde5ed43fbaabbc1a69f09b7fc3a47 ] In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist putting each entry into 'sg', but the entry length is read from 'sgl' (the list head) instead of 'sg' (the current entry): for_each_sg(sgl, sg, sg_len, i) { addr = sg_dma_address(sg); avail = sg_dma_len(sgl); /* should be 'sg' */ Consequently 'avail' is always the length of the first entry. For multi-sg lists this causes out-of-bounds reads when a later entry is shorter than the first, and silent data loss when it is longer. Single-sg or uniformly-sized lists happen to mask the issue. Fixes: c8acd6aa6bed3 ("dmaengine: mmp-pdma support") Signed-off-by: Baineng Shou Reviewed-by: Frank Li Link: https://patch.msgid.link/20260910021652.1296640-1-shoubaineng@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 879907631b9e70eedb62d76461b29afa106ebe7a Author: Eric Dumazet Date: Sat Sep 12 14:48:48 2026 +0000 tcp: do not let tcp_rmem be set below 4096 [ Upstream commit 83a945a529d6e002dd7339c532288a931f463dba ] We can hit a division by zero crash in tcp_rcvbuf_grow() and tcp_rcv_space_adjust(): divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcp_rcvbuf_grow+0x187/0x450 net/ipv4/tcp_input.c:939 ... grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval); The division uses oldval = tp->rcvq_space.space as divisor. When tp->rcvq_space.space is zero, this leads to a divide-by-zero exception. tp->rcvq_space.space is initialized in tcp_init_buffer_space(): tp->rcvq_space.space = min3(tp->rcv_ssthresh, tp->rcv_wnd, (u32)TCP_INIT_CWND * tp->advmss); If tcp_rmem[1] is configured to very small values (such as 1), sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which computes (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0. This sets tp->window_clamp = 0, tp->rcv_ssthresh = 0, and tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked, tcp_rcvbuf_grow() divides by oldval == 0. Back in 2015, commit b1cb59cf2efe ("net: sysctl_net_core: check SNDBUF and RCVBUF for min length") ensured that net.core.rmem_default and net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF. Similarly, SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF). However, net.ipv4.tcp_rmem still had .extra1 = SYSCTL_ONE, allowing arbitrarily small values. Because SOCK_MIN_RCVBUF depends on sizeof(struct sk_buff) and cacheline alignment, its value varies across architectures and configuration options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that is safely above SOCK_MIN_RCVBUF everywhere and matches the documented 4K default. Fix this by setting tcp_rmem.extra1 to 4096 and updating the documentation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912144848.3448026-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a23a3bc5004df6434de05797e0b6b2ecf864b86a Author: Kuniyuki Iwashima Date: Mon Sep 14 01:14:01 2026 +0000 tcp: Don't call skb_clone_and_charge_r() for close()d listener in tcp_v6_do_rcv(). [ Upstream commit 8e759cd1f6444a946bd1fd2b2b29eea582eea1d5 ] tcp_v6_do_rcv() no longer calls skb_clone_and_charge_r() for TCP_LISTEN since commit 073d89808c06 ("net: fix data-races around sk->sk_forward_alloc"). However, there is still a small race window between tcp_v6_rcv() and tcp_v6_do_rcv(), where concurrent close() changes TCP_LISTEN to TCP_CLOSE, causing skb_clone_and_charge_r() to be called locklessly and resulting in the splat below. [0] Let's avoid calling skb_clone_and_charge_r() for TCP_CLOSE as well. This is fine for non-listeners because tcp_rcv_state_process() drops skb for TCP_CLOSE and opt_skb was freed immediately anyway. [0]: sk->sk_forward_alloc WARNING: net/ipv4/af_inet.c:162 at inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162, CPU#1: ksoftirqd/1/28 Modules linked in: CPU: 1 UID: 0 PID: 28 Comm: ksoftirqd/1 Not tainted 7.2.0 #17 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162 Code: 3d 49 ff e9 06 fd ff ff e8 d0 5b 83 f8 90 0f 0b 90 e9 35 fe ff ff e8 c2 5b 83 f8 90 0f 0b 90 e9 c5 fe ff ff e8 b4 5b 83 f8 90 <0f> 0b 90 e9 04 ff ff ff e8 a6 5b 83 f8 90 0f 0b 90 e9 65 fe ff ff RSP: 0018:ffffc90000677bb8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880117bde80 RCX: ffffffff8957eb41 RDX: ffff88801dad5d00 RSI: ffffffff8957ec3c RDI: 0000000000000005 RBP: 00000000fffff000 R08: ffffffff8957eb41 R09: 00000000fffff000 R10: 0000000000000005 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff8880117bdf10 R14: ffffffff81c08eb7 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880d7ae5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93a1021138 CR3: 00000000207a9000 CR4: 0000000000350ef0 Call Trace: __sk_destruct+0x82/0xae0 net/core/sock.c:2356 rcu_do_batch kernel/rcu/tree.c:2645 [inline] rcu_core+0x59c/0x1100 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9b0 kernel/softirq.c:622 run_ksoftirqd kernel/softirq.c:1076 [inline] run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068 smpboot_thread_fn+0x458/0xc80 kernel/smpboot.c:160 kthread+0x396/0x4a0 kernel/kthread.c:436 ret_from_fork+0x8e0/0xe40 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets") Reported-by: Taras Madan Signed-off-by: Kuniyuki Iwashima Reviewed-by: Xuanqiang Luo Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914011420.115556-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 85b40e4c5288c846b7f9328f669f7e69df52213b Author: Karl Mehltretter Date: Tue Aug 11 10:27:02 2026 +0200 wifi: brcmfmac: fix lost 802.1x TX completion wakeup [ Upstream commit 621d90169cef6c8da5b6134db5c0c4e23cdd09ce ] brcmf_txfinalize() decrements pend_8021x_cnt before a lockless waitqueue_active() check. atomic_dec() does not order the decrement against the check. The waiter can therefore observe a nonzero count while the waker observes an empty queue, losing the final wakeup and delaying key installation until the 950 ms timeout. Add smp_mb__after_atomic() to order the decrement before the queue check. wait_event_timeout() provides the matching barrier. LKMM confirms that this forbids the lost-wakeup outcome. Fixes: 21fff75d2fb6 ("brcmfmac: use wait_event_timeout for 8021x pending count") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260811082702.44521-1-kmehltretter@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 835903bea770ad96ab4322e18d98e00f8e0b39c3 Author: Hohyun Sim Date: Thu Sep 10 15:37:43 2026 +0900 net: fddi: skfp: fix NULL deref when setting the MAC address while down [ Upstream commit 7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1 ] skfp_ctl_set_mac_address() calls ResetAdapter() unconditionally, without checking netif_running(). ResetAdapter() first calls card_stop(), which sets smc->hw.hw_state to STOPPED, and then mac_drv_clear_tx_queue(), which walks the two transmit queues: for (i = QUEUE_S; i <= QUEUE_A0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->tx_curr_get ; smc->hw.fp.tx[] is only populated by init_tx(), which is reached from skfp_open() through init_smt() -> init_fddi_driver() -> init_fplus() -> init_mac() -> init_tx(). The private area is allocated and zeroed by alloc_fddidev(), so on an interface that has never been brought up both queue pointers are still NULL. The hw_state test at the top of mac_drv_clear_tx_queue() does not catch this, because card_stop() has just set STOPPED; the function proceeds into the loop and dereferences NULL. ResetAdapter() does call init_smt() itself, but only after the queues have been cleared. Setting the MAC address on a down interface therefore oopses: ip link set dev fddi0 address 02:00:00:00:00:01 BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netif_set_mac_address+0x1e4/0x2c0 do_setlink+0x684/0x2680 Address 0x10 is the offset of tx_curr_get, the third pointer in struct s_smt_tx_queue, on 64-bit. mac_drv_clear_rx_queue(), which ResetAdapter() calls immediately afterwards, dereferences smc->hw.fp.rx[QUEUE_R1] in the same way behind the same ineffective hw_state test; the transmit queue merely crashes first. Both are covered by the guard below. Skip the adapter reset when the interface is down. dev_addr_set() is left unconditional, so the new address is still recorded in dev->dev_addr. Nothing is lost by not resetting the adapter here: skfp_open() deliberately re-reads the factory address on every open, read_address(smc, NULL); eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a); and the comment above it states this is done to discard exactly such an address override across a close/open cycle. An address set while the interface is down could not have survived the following open even before this change, so the guard removes no working behaviour. Guarding the hardware side of ndo_set_mac_address() with netif_running() is established practice; skge_set_mac_address() has done so since commit 2eb3e621c4e0 ("skge: set mac address bonding fix"). Guarding the reset as a whole, rather than NULL-checking the queues, is also what the rest of the driver expects. After a previous open/close the queue pointers are stale but non-NULL, so there is no crash, yet ResetAdapter() goes on to call smt_online() and STI_FBI() ("Enable Board Interrupts") while skfp_close() has already called free_irq() - the adapter would be brought back online with no handler installed. The only other ResetAdapter() caller is skfp_interrupt(), which by construction runs only while the device is open. Found by automated driver testing against an emulated SysKonnect FDDI adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires CAP_NET_ADMIN. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM KASAN Signed-off-by: Hohyun Sim Link: https://patch.msgid.link/20260910063743.110747-1-tlaghgus0425@korea.ac.kr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1d9f5c78903dd25a3556229eb716dd465c5f3573 Author: Andrea Mayer Date: Sun Sep 13 21:44:21 2026 +0200 seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation [ Upstream commit 7616242a2b37883f7322aaa1d2bd6cd0fed28315 ] When an SRv6 packet arrives on an interface enslaved to a VRF, vrf_ip6_rcv() sets IP6SKB_L3SLAVE in IP6CB, but decap_and_validate() has never set IPSKB_L3SLAVE in IPCB. The bit stayed clear in the common case, and with CONFIG_IPV6_MIP6 the leftover frag_max_size of a reassembled outer packet could even set it, with no VRF involved. Commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") then made the unreliable bit reliably clear. The effect of the missing flag is visible with End.DX4 when a delivery to a local address of the node reaches the socket lookup. For example, a UDP socket bound to the enslaved ingress interface does not receive any of the decapsulated packets, while an unbound socket outside the VRF does. This contradicts Documentation/networking/vrf.rst: by default the scope of an unbound UDP or TCP socket is limited to the default VRF. Set IPSKB_L3SLAVE for IPv4 in decap_and_validate(), which already does the same for IPv6. The socket lookup then matches the decapsulated packet like any other packet received on that enslaved interface. Such a packet matches an unbound UDP or TCP socket only when udp_l3mdev_accept or tcp_l3mdev_accept is set. Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions") Signed-off-by: Andrea Mayer Reviewed-by: David Ahern Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260913194421.31-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4e54829d9793b221b185a7f479ed44c49373a642 Author: Filipe Manana Date: Thu Sep 10 17:37:48 2026 +0100 btrfs: tree-checker: print dev extent offset in error message [ Upstream commit a1167d9420474ab9ed9efca99d86aeb6217c0265 ] If a dev extent's offset is not sector size aligned, the error message is printing the dev extent's objectid instead of the offset. This is a copy paste error, as before this check we check the objectid field. Fixes: 008e2512dc56 ("btrfs: tree-checker: add dev extent item checks") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5a4c974dee03cc46eac43c82f33e34ec94f0b348 Author: Slavin Liu Date: Sun Sep 13 20:51:54 2026 +0800 ALSA: hda: trace PCM open only after assigning a stream [ Upstream commit c9e6e5f38bf75276605f1952b22285f5f3abcaff ] Stream assignment can fail when hardware streams are exhausted. Move the tracepoint after the NULL check because its payload accesses the assigned stream tag. Detected by static analysis and reviewed with AI-assisted source auditing. Fixes: 184865085b88 ("ALSA: hda - rename hda_intel_trace.h to hda_controller_trace.h") Assisted-by: LLM Signed-off-by: Slavin Liu Link: https://patch.msgid.link/20260913125154.109944-1-bolin.liu@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ee9ea1afd6990def51d52b3a0aecd5cfcc951da0 Author: Zihan Xi Date: Wed Sep 9 12:37:18 2026 +0000 wifi: virt_wifi: don't transfer operstate before register [ Upstream commit e5c8d7acd31b27057ea42cd405d0b3ece097bc89 ] virt_wifi_newlink() calls netif_stacked_transfer_operstate() before register_netdevice(). If the lower device is dormant, that queues the new netdev on lweventlist while it is still uninitialized. If registration fails after that, for example because of an invalid name such as "bad/name", free_netdev() immediately frees the object. A later linkwatch_fire_event() then use-after-frees the list entry. Move the transfer to after netdev_upper_dev_link(), as macvlan and ipvlan already do. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Link: https://patch.msgid.link/f5a832fb0ab228ce6e2b5a91fba4ca8b79198a2f.1788948455.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1aa5a4d389ba5da3ecc1abaab4e30a3851046c97 Author: Karl Mehltretter Date: Sat Sep 5 12:20:38 2026 +0200 Input: trackpoint - fix the inertia attribute name in the ABI document [ Upstream commit 45b0037899704caf9078be2be4de69361ca7d933 ] The attribute is created as "inertia" (TRACKPOINT_INT_ATTR(inertia, ...) in drivers/input/mouse/trackpoint.c); the ABI file spells the path "intertia". The description below it already says inertia. Fix the spelling. Fixes: aebb47d4e7a9 ("Input: trackpoint: document sysfs interface") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260905102038.42882-1-kmehltretter@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 27f167e117eca310661fbcbacb352ea08face067 Author: Nguyen Ngoc Thang Date: Sun Sep 13 20:44:46 2026 +0700 ALSA: pcm: set timer->private_data before registering the PCM timer [ Upstream commit 1e713f9bb2ac583521f06b0eb4e22440b1e3d078 ] snd_pcm_timer_init() calls snd_device_register() to link the new struct snd_timer into the global timer list while it still carries hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop), and only afterwards sets timer->private_data = substream. Once the timer is on the list under register_mutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via c_resolution(), and snd_timer_open()+snd_timer_start() reach start()/stop() the same way. All three dereference timer->private_data, which for this brief window is NULL, giving a NULL-pointer dereference: substream = timer->private_data; return substream->runtime ? ... // substream is NULL Move the private_data/private_free assignment before snd_device_register() so the timer is never visible on the list without its private_data set. On the snd_device_register() failure path, private_free() (snd_pcm_timer_free()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe. Reported-by: syzbot+19da64013c46df87f971@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=19da64013c46df87f971 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260913134446.114724-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aa15e0f5ec4ed9573fa5d283400a28dd51065b83 Author: Karl Mehltretter Date: Fri Aug 21 04:53:27 2026 +0200 keys: fix lost wakeup when reaping a dead key type [ Upstream commit 2725ab3f5ad1c5f375c7c9fee4af02a9b138f701 ] clear_bit() is atomic with respect to the word it modifies, but it is an unordered operation: it implies no memory barrier on either side (Documentation/atomic_bitops.txt). key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit() and calls wake_up_bit() after reaping a dead key type. wake_up_bit() uses a lockless waitqueue check and requires a full barrier after the clear. The existing smp_mb() is before clear_bit(), so nothing orders the clear against that check. The GC can see an empty waitqueue while unregister_key_type() still sees the bit set. The final wakeup is then lost, leaving module unload stuck in wait_on_bit(). Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE semantics, so the completed GC work stays ordered before the clear, and its smp_mb__after_atomic() orders the clear before the waitqueue check. Fixes: 0c061b5707ab ("KEYS: Correctly destroy key payloads when their keytype is removed") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 3d6576ed3de01e8a378397b7020e33ae3d40aa6c Author: Thadeu Lima de Souza Cascardo Date: Wed Aug 26 08:46:58 2026 -0300 drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr [ Upstream commit 9eb1a393c89a79c4210230d23e7d88d239c61d7b ] When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not set, a drm_pending_vblank_event will be allocated. If later, there is an allocation failure or another failure at setup_out_fence(), that event will not have base.fence set and it will not be released at complete_signaling(). Release the event and set crtc_state->event to NULL just like in the DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at drm_event_reserve_init(). That is, prepare_signaling() releases the event and there is nothing to be done at complete_signaling(). Use drm_event_cancel_free() as that will also undo drm_event_reserve_init() in case it has been called. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com?part=1 Fixes: 92c715fca907 ("drm/atomic: Fix double free in drm_atomic_state_default_clear") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260826-drm_pending_vblank_event_leak-v4-1-f8de8b996b9d@igalia.com Signed-off-by: Sasha Levin commit 93ff1594be1aad4da364462dd8db050ebcfda2de Author: Pablo Neira Ayuso Date: Mon Sep 7 21:04:05 2026 +0200 netfilter: flowtable: hold reference on ct until flow is released [ Upstream commit e75a9fa1d44bcbd66ea02e8781bcca6ea4076e0d ] nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period. Add rcu_barrier() on module exit path, to ensure pending flow entries are release before module goes away. Fixes: 0ff90b6c2034 ("netfilter: nf_flow_offload: fix use-after-free and a resource leak") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 29365695842db0a97b701a43a09fad1b4f7ecf3e Author: Theodor Arsenij Larionov Trichkine Date: Tue Aug 25 12:10:56 2026 +0300 netfilter: nft_nat: fully initialise new_addr in netmap setup [ Upstream commit d313499df66159b4b7971d760d16729598ab7e5a ] nft_nat_setup_netmap() builds the mapped address in an on-stack union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip member and the loop runs a single 32-bit iteration, but it then copies the whole 16-byte union into range->min_addr and range->max_addr, so the upper 12 bytes reach nf_nat_setup_info() uninitialised. KMSAN reports an uninit-value in nf_nat_setup_info() reached from nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected. Zero-initialise new_addr. Fixes: 3ff7ddb1353d ("netfilter: nft_nat: add netmap support") Signed-off-by: Theodor Arsenij Larionov Trichkine Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2c6fbcf4bfac0b2b186acc8d91154c0fa24468a7 Author: Jérémy Jean Date: Tue Sep 8 08:55:20 2026 +0000 RDMA/siw: Bound fragmented header copies by the remaining length [ Upstream commit 9ff797e516dbc1ecb73701ec4c24055712d44411 ] siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length. Fixes: 754209850df8 ("RDMA/siw: Always consume all skbuf data in sk_data_ready() upcall.") Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260908085520.1746329-1-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-6 Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e12c5e1634ad837a88e19e608143c6eeaf08334a Author: Alex Bereza Date: Tue Aug 18 09:36:29 2026 +0200 dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic DMA [ Upstream commit 7ed1e3070c9b4bbd67d5519e14711038dd53ab13 ] Using the DMA in cyclic mode modifies the hardware buffer descriptor chain in xilinx_dma_prep_dma_cyclic so that the last descriptor used by the cyclic transfer points back to the first descriptor, but it never restores the original descriptor ring. This breaks using non-cyclic mode after cyclic mode with an error like: xilinx-vdma 86000000.dma: Channel 00000000354d5c8d has errors 100, cdr 6de40000 tdr 6de40400 The only way to get out of this error state is to rebuild the hardware buffer descriptor ring by releasing and re-acquiring the channel. Fix using non-cyclic mode after cyclic mode by always restoring the original buffer descriptor ring in the same manner as it is set up by xilinx_dma_alloc_chan_resources(). Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-after-cyclic-mode-v1-1-1fe47e701d6c@bereza.email Link: https://patch.msgid.link/20260818-fix-hw-buf-desc-after-cyclic-mode-v2-1-530ff44c6a81@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 286fa87504092bcef9e44387ef8128455abbc408 Author: Alex Bereza Date: Mon Aug 17 11:23:55 2026 +0200 dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order [ Upstream commit cee9c863ee68cb27d66745eb03f60e357f4f8ad2 ] xilinx_dma_alloc_chan_resources() builds a static ring of hardware buffer descriptors once and the driver uses this ring throughout the lifetime of a channel. This requires the allocation order of hardware buffer descriptors from chan->free_seg_list to stay in sync with the hardware buffer descriptor ring built at channel allocation time by returning oldest descriptors to chan->free_seg_list first. When chan->pending_list is not empty e.g. during xilinx_dma_terminate_all() the chan->free_seg_list and the order of the static hardware buffer descriptor ring get out of sync. Descriptors age in this order: pending -> active -> done. So freeing pending_list first returns the newest buffer descriptors to the chan->free_seg_list first and thus breaks the order required by the static hardware buffer descriptor ring. Then when the channel is reused, after a wrap around of the free_seg_list the DMA will find a hardware buffer descriptor with a length field that is still zeroed and stop with something like this: xilinx-vdma 86000000.dma: Channel 000000003a21d7b8 has errors 10, cdr 6de4c000 tdr 6de4c000 After this no more descriptors are completed and a consumer potentially blocks and waits forever. The only way to get out of this error state is to rebuild the static hardware buffer descriptor ring and the free_seg_list by releasing and re-acquiring the channel. Fix the order in which hardware buffer descriptors are returned to free_seg_list to ensure the mentioned requirement holds. Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-reuse-v1-1-d79827a844c7@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8f6c7c02462f5e7abbb0aa8d00a04ff3af9a1520 Author: Johannes Berg Date: Tue Sep 8 14:28:17 2026 +0200 wifi: mac80211: don't access the TSF of a down interface [ Upstream commit 0b1de9feeb8651f7a3bb53ed7c9006e3b5298c01 ] The tsf debugfs files call the driver even if the interface isn't up, tgriggering check-sdata-in-driver warnings. Reject the access in that case. Assisted-by: LLM Fixes: 37a41b4affa3 ("mac80211: add ieee80211_vif param to tsf functions") Reported-by: syzbot+1c8c45017f784e646b47@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1c8c45017f784e646b47 Link: https://patch.msgid.link/20260908122838.201719-18-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8831287b8def5f7bb203fcdba6f39c76d266d53d Author: Johannes Berg Date: Tue Sep 8 14:28:16 2026 +0200 wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set [ Upstream commit b481e64e4498e2c053d5954f546ee02338f6ab63 ] In the error path of ieee80211_mesh_csa_beacon() the settings that were just assigned are read back with rcu_dereference(), which lockdep then complains about. There's no need to read the pointer at all, tmp_csa_settings still is the right value anyway. Assisted-by: LLM Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Reported-by: syzbot+b59873f5699e941717ca@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b59873f5699e941717ca Link: https://patch.msgid.link/20260908122838.201719-17-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b0b32d3f163d24ea7134380666193bf398e9dc0b Author: Johannes Berg Date: Tue Sep 8 14:28:13 2026 +0200 wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown [ Upstream commit 4504f3960dc4501c73be9f99eabda2e26e9db41e ] On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that. Assisted-by: LLM Fixes: f9dca80b98ca ("mac80211: fix AP_VLAN crypto tailroom calculation") Reported-by: syzbot+de3ee5362db09487ea37@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de3ee5362db09487ea37 Link: https://patch.msgid.link/20260908122838.201719-14-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6ef87a853327434ae1cd9c5a2c27a557fb4047fc Author: Johannes Berg Date: Fri Sep 4 16:55:05 2026 +0200 wifi: cfg80211: don't filter by BSS type when removing stale entries [ Upstream commit b377e1000d963e7182a987082b4b06580bd7ac84 ] When an assoc AP switches to a channel that already has a BSS entry, cfg80211_update_assoc_bss_entry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree. The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211_rehash_bss() then ran into it: WARN_ON(!cmp) Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison. Assisted-by: LLM Fixes: 0afd425b1b64 ("cfg80211: fix duplicated scan entries after channel switch") Reported-by: syzbot+dc6f4dce0d707900cdea@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dc6f4dce0d707900cdea Link: https://patch.msgid.link/20260904165614.1f05dae1c546.Ib52d57b57caa912efee020f9d4a033a5160617ce@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4cd6a518ce7527284bbc9baab5fa2453a7d477c2 Author: Johannes Berg Date: Fri Sep 4 16:55:04 2026 +0200 wifi: cfg80211: only group hidden BSSes with beacon entries [ Upstream commit 068843ed0902c552a13860c5ec6b2ca65b57a065 ] When a probe response for an unknown BSS comes in, __cfg80211_bss_update() looks for an existing entry with the same BSSID and a hidden (zero-length or NUL-filled) SSID, and if it finds one it groups them, using the beacon IEs from the existing entry. But that could find another entry without a beacon, if it was also from a probe response (with SSID), so there's a group without beacon elements. If a beacon with a hidden SSID for that BSSID arrives later, cfg80211_combine_bsses() goes looking for the probe response entries that belong to it - i.e. entries with the same BSSID and channel that have no beacon IEs - and finds those two. They are already grouped with each other, so it hits its WARN_ON_ONCE(bss->pub.hidden_beacon_bss) WARN_ON_ONCE(!list_empty(&bss->hidden_list)) which are there because an entry without beacon elements is not supposed to be part of a group yet. Only combine entries when a beacon was already received, ones that are kept separate will be combined when a beacon arrives. Assisted-by: LLM Fixes: 4593c4cbe1c9 ("cfg80211: fix BSS list hidden SSID lookup") Reported-by: syzbot+1a797e1c81be78a2ace7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1a797e1c81be78a2ace7 Link: https://patch.msgid.link/20260904165614.bcfa64715745.Iad740347c86de56d4ff4f96a95f3c3afc47c42de@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ac8ce9f89638d6d79875cca7d8ae42566a9bde15 Author: Shivank Garg Date: Sat Aug 22 19:22:06 2026 +0000 dmaengine: wait for RCU readers before releasing dma_device [ Upstream commit dc750422170a563c7a81f6e49d36bb02c62ae37f ] dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()). Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed. The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list. Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed. Fixes: 2ba05622b8b1 ("dmaengine: provide a common 'issue_pending_all' implementation") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260526-dmaengine-kref-fix-v2-0-3df60afac01d@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-4-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b92c502595336a3cc5bb7a060170891366745a5d Author: Shivank Garg Date: Sat Aug 22 19:22:05 2026 +0000 dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel() [ Upstream commit e873c74132f0c5f1452816cd9bb26208f0bba1e1 ] When dma_device_put() drops the last reference on chan->device->ref, dma_device_release() runs and may free the dma_device along with its channels. dma_chan_put() then still reads chan->device->owner via dma_chan_to_owner() for the trailing module_put(). KASAN catches it: slab-use-after-free in dma_chan_put+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dma_chan_put+0x395/0x4c0 dmaengine_put+0xf8/0x160 Cache the module owner in dma_chan_put() before the put so the trailing module_put() does not need chan->device. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-3-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 036b527f92570206da4b8c40b38f8d689e29d0f3 Author: Shivank Garg Date: Sat Aug 22 19:22:04 2026 +0000 dmaengine: Fix device kref underflow in dma_chan_put() [ Upstream commit 44dab659064eb5c10adb0306510eebe848ed592d ] dma_chan_get() takes chan->device->ref only on the slow path: /* no kref on fast path */ if (chan->client_count) { __module_get(owner); chan->client_count++; return 0; } if (!try_module_get(owner)) return -ENODEV; if (!dma_device_get(chan->device)) { // calls kref_get_unless_zero() dma_chan_put() drops the ref unconditionally, so every fast-path get/put pair drops one extra device reference. The bug fires when two conditions hold together: a non-private provider has a persistent client holding chan->client_count > 0 and another client cycles dmaengine_get()/dmaengine_put(). When the kref hits zero, the subsequent dma_find_channel() returns NULL even though the provider module is still loaded. Fix this by dropping device->ref only on the last put, matching the single slow-path get. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-2-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 305672ef858eade8865ed544e25d1212944f6d2f Author: Donggeun Yoo Date: Sat Sep 5 16:47:27 2026 +0900 dma-coherent: report a failed reserved memory assignment [ Upstream commit 504981db4f69bdd28054fb98c96a3a67f7248dde ] rmem_dma_device_init() drops the return value of dma_assign_coherent_memory() and always reports success. That call fails with -EBUSY when the device already has a coherent pool, and the file allows only "*one* such region of memory" per device. of_reserved_mem_device_init_by_idx() reads the zero as success. It logs "assigned reserved memory node" for a region that was not assigned and records the pairing, so of_reserved_mem_device_release() later runs rmem_dma_device_release() for it. That clears dev->dma_mem without looking at which region it was called for, dropping the pool the device did get and leaving it on ordinary memory. dma_declare_coherent_memory() checks the same call and releases the memory on failure, and rmem_swiotlb_device_init() propagates its own errors. Return the error here as well, so a device tree that assigns two pools to one device fails the probe instead of half working. Fixes: 7bfa5ab6fa1b ("drivers: dma-coherent: add initialization from device tree") Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260905074727.108029-1-donggeunyoo.kernel@gmail.com Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 89d49c0f2b55c1df23e0c28512b251c3fcb18302 Author: Chen-Yu Tsai Date: Mon Apr 21 16:39:29 2025 +0800 dma-coherent: Warn if OF reserved memory is beyond current coherent DMA mask [ Upstream commit 89461db349cc00816c01d55507d511466b3b7151 ] When a reserved memory region described in the device tree is attached to a device, it is expected that the device's limitations are correctly included in that description. However, if the device driver failed to implement DMA address masking or addressing beyond the default 32 bits (on arm64), then bad things could happen because the DMA address was truncated, such as playing back audio with no actual audio coming out, or DMA overwriting random blocks of kernel memory. Check against the coherent DMA mask when the memory regions are attached to the device. Give a warning when the memory region can not be covered by the mask. A warning instead of a hard error was chosen, because it is possible that existing drivers could be working fine even if they forgot to extend the coherent DMA mask. Signed-off-by: Chen-Yu Tsai Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20250421083930.374173-1-wenst@chromium.org Stable-dep-of: 504981db4f69 ("dma-coherent: report a failed reserved memory assignment") Signed-off-by: Sasha Levin commit bddf49f493fbbe211a2975e3d4787b4ff5d14af8 Author: Christoph Hellwig Date: Wed Jun 23 16:00:04 2021 +0200 dma-mapping: simplify dma_init_coherent_memory [ Upstream commit a6933571f34a9aee843fff2aa4b96949c57d6274 ] Return the allocated dma_coherent_mem structure, set the use_dma_pfn_offset and print the failure warning inside of dma_init_coherent_memory instead of leaving that to the callers. Signed-off-by: Christoph Hellwig Tested-by: Dillon Min Stable-dep-of: 504981db4f69 ("dma-coherent: report a failed reserved memory assignment") Signed-off-by: Sasha Levin commit acfd3b5a30704df93277def251380d1f16a32498 Author: Orgad Shaneh Date: Tue Sep 1 19:33:55 2026 +0000 MIPS: Octeon: apply USB FDT fixups also when USB is modular [ Upstream commit 126f16e0a1b353c2ba5c7e2c8626cfa865934f9f ] The uctl/usbn device-tree fixups in octeon_prune_device_tree() - which set the board's USB reference-clock frequency and type from __cvmx_helper_board_usb_get_clock_type() - are guarded by "#ifdef CONFIG_USB", which is false when USB is built as a module. The fixups then silently disappear and octeon-hcd sees whatever default the DTS carries (12MHz crystal in octeon_3xxx.dts), leaving the PHY dead or the bus erroring on boards with a different reference clock. Use IS_ENABLED() so USB=m gets the same fixups as USB=y. Fixes: 7fd57ab9d9cf ("MIPS: Octeon: Fix compile error when USB is not enabled.") Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit cd72c957bad13f0efa3974f147642ff074ae5c4a Author: Bard Liao Date: Tue Sep 1 11:10:19 2026 +0800 soundwire: cadence_master: wait and cancel cdns->work before clock stop [ Upstream commit aba7b41faeecb7692458095ce6fafc341fe0b80e ] A peripheral event could happen during the clock stop process. We need to wait for the event be handled before stopping the bus clock. Otherwise, we will get the IO transfer timed out issue. Fixes: af4cc917826f ("soundwire: cadence: mask Slave interrupt before stopping clock") Signed-off-by: Bard Liao Reviewed-by: David Lin Reviewed-by: Shuming Fan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260901031019.233254-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 18d5547327c202cda33ad2bbd203220c2c62c8a7 Author: Johannes Berg Date: Fri Sep 4 16:55:02 2026 +0200 wifi: cfg80211: check IP header size in cfg80211_classify8021d() [ Upstream commit 48b2c5c628b09cf36cbeca53e0432fc2a7518be7 ] A frame that looks like IP can be transmitted, but be too short, so the DS field is read incorrectly: BUG: KMSAN: uninit-value in cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 ieee80211_select_queue+0x37a/0x9e0 net/mac80211/wme.c:180 __ieee80211_subif_start_xmit+0x60f/0x1d90 net/mac80211/tx.c:4304 ieee80211_subif_start_xmit+0xa8/0x6d0 net/mac80211/tx.c:4538 ... packet_sendmsg+0x9173/0xa2a0 net/packet/af_packet.c:3108 Use skb_header_pointer() like the MPLS case. Assisted-by: LLM Fixes: e31a16d6f64e ("wireless: move some utility functions from mac80211 to cfg80211") Reported-by: syzbot+878ddc3962f792e9af59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=878ddc3962f792e9af59 Link: https://patch.msgid.link/20260904165614.5e61a4c80b92.I37d68d3f406cb3b90b32e6943418d66070b65197@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f973769fb7cb33ba0d4a64b7dcfee0cabaead938 Author: Carolina Jubran Date: Wed Sep 2 17:06:32 2026 +0300 IB/IPoIB: Avoid restoring OPER_UP after multicast flush [ Upstream commit 9a141d3dc869d18b2eab35e999f4790a9b84e40f ] ipoib_ib_dev_flush_light() temporarily clears IPOIB_FLAG_OPER_UP to prevent multicast joins while ipoib_mcast_dev_flush() is running, and restores the flag afterwards if it was previously set. This restore races with ipoib_ib_dev_down(). If the interface is brought down while the flush is in progress, ipoib_ib_dev_down() clears IPOIB_FLAG_OPER_UP, but the flush path may set it again after the device has already gone down. Since commit 894021a75291 ("IB/ipoib: Make the carrier_on_task race aware"), ipoib_mcast_carrier_on_task() relies on IPOIB_FLAG_OPER_UP being cleared to terminate its rtnl_trylock() retry loop. If the flag is left set after shutdown, the workqueue retries forever, causing teardown to deadlock when ipoib_ndo_uninit() waits in destroy_workqueue() while holding RTNL. Instead of overloading IPOIB_FLAG_OPER_UP to block multicast joins during a light flush, introduce a dedicated IPOIB_FLAG_MCAST_FLUSH flag. Use it together with IPOIB_FLAG_OPER_UP to determine whether multicast joins are allowed, avoiding the race with device shutdown. Fixes: 344bacca8cd8 ("IB/ipoib: Don't allow MC joins during light MC flush") Reported-by: Ben Davies Signed-off-by: Carolina Jubran Reviewed-by: Cosmin Ratiu Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260902-avoid-rest-oper-up-v1-1-04fcd4916cae@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 766268b429ae26d8ca599031fa962b0fe4673120 Author: Shmulik Cohen Date: Wed Aug 12 22:04:11 2026 +0300 wifi: libipw: reject too-short association responses [ Upstream commit adb7118b7d2cfd7e8213c17d7d2829f353017754 ] libipw_handle_assoc_resp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as stats->len - sizeof(*frame) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer. Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. Fixes: 9e8571affd1c ("[PATCH] ieee80211: Add QoS (WME) support to the ieee80211 subsystem") Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-3-anuk909@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cee6f141b3bebe62eb0363fd147acb52023935f0 Author: Shmulik Cohen Date: Wed Aug 12 22:04:10 2026 +0300 wifi: libipw: reject too-short beacon and probe responses [ Upstream commit 5ce5721e8cbe3e80db8f43851cc2a2a92485ef4b ] libipw_process_probe_response() and the libipw_network_init() call it makes assume the frame contains the full 36-byte beacon and probe response prefix, but the ipw2100 and ipw2200 receive paths only establish that a management frame carries the generic 24-byte three-address header. libipw_network_init() then computes the information element length as stats->len - sizeof(*beacon) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() yields 65524 for a 24-byte beacon, and the parser then walks the receive buffer as if it held almost 64 KiB of information elements, reading past the allocation. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. Fixes: b453872c35cf ("[NET] ieee80211 subsystem") Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-2-anuk909@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 11bc2cbb14f450eaa47cce9eb086f948ef8f4bcd Author: Peng Hao Date: Fri Aug 28 19:15:31 2026 +0800 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path [ Upstream commit a3d722190cdef18da4878b5efc27c3c386dda248 ] mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the failed index's &card->msix_ctx[i] as the dev_id. free_irq() matches on (irq, dev_id), so it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and free_irq() warns about freeing a non-existent IRQ. Use &card->msix_ctx[j]. Fixes: 99074fc1e67b ("mwifiex: enable pcie MSIx interrupt mode support") Signed-off-by: Peng Hao Link: https://patch.msgid.link/20260828111531.56723-1-flyingpeng@tencent.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 38d3a5df85345f158f78b478b265ca906224454e Author: Mariano Baragiola Date: Sun Aug 9 09:49:47 2026 -0300 wifi: virt_wifi: free skb when disconnected [ Upstream commit f9edf7cf63b96d2b776fca8d258d3c5256e40c8e ] When the simulated link is disconnected, virt_wifi_start_xmit() returns NET_XMIT_DROP without freeing the skb. dev_hard_start_xmit() treats this return value as consumed, so every packet sent while disconnected leaks its skb. Free the skb before returning the drop status. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Signed-off-by: Mariano Baragiola Link: https://patch.msgid.link/20260809124947.3590270-1-mbaragiola@linux.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0a5cdb483956f8bc57f8de5df773523627aeb5c0 Author: Ruoyu Wang Date: Thu Aug 13 23:31:49 2026 +0800 dmaengine: sprd: Fix runtime PM reference leak in probe [ Upstream commit a7df136ec529ee49a789c5029bc37b98b0d4bedd ] pm_runtime_get_sync() increments a device's usage counter even when it fails. sprd_dma_probe() currently jumps directly to controller clock cleanup on that error, bypassing both pm_runtime_put_noidle() and pm_runtime_disable(). This can happen if the preceding unchecked pm_runtime_set_active() fails and the following runtime-resume attempt also returns an error. Enter the existing runtime-PM unwind path instead. This drops the reference without idling the partially initialized device, disables runtime PM, and then releases the controller clocks. The success path and propagated error code are unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 9b3b8171f7f4 ("dmaengine: sprd: Add Spreadtrum DMA driver") Signed-off-by: Ruoyu Wang Reviewed-by: Frank Li Reviewed-by: Baolin Wang Link: https://patch.msgid.link/20260813153149.3953497-1-ruoyuw560@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4617c9a856188674dddb0ca66979746d07688579 Author: Li RongQing Date: Wed Aug 26 15:32:16 2026 +0800 RDMA/mad: Fix receive buffer leak when PKey enforcement fails [ Upstream commit 3476c28c9addfa253f505e6bd87f1f5598b961d0 ] ib_mad_complete_recv() initializes mad_recv_wc->rmpp_list and then runs ib_mad_enforce_security() before linking recv_buf onto that list. On failure it calls ib_free_recv_mad(), which only walks rmpp_list and frees the ib_mad_private of every buffer found there. As the list is still empty at that point, nothing is freed at all. The caller cannot clean up either: ib_mad_recv_done() sets recv to NULL right after ib_mad_complete_recv() returns, assuming the MAD layer took ownership of the buffer. Every MAD that fails the PKey check therefore leaks one ib_mad_private (about 300 bytes per IB port MAD, ~2K for OPA), and a remote node can trigger this repeatedly by sending MADs with a wrong PKey. Link recv_buf onto rmpp_list right after the list is initialized, so the error path has something to free. Fixes: 47a2b338fe63 ("IB/core: Enforce security on management datagrams") Signed-off-by: Li RongQing Link: https://patch.msgid.link/20260826073216.2367-1-lirongqing@baidu.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f5613acbe2e346d5c466ef0bd264fca936b69f82 Author: Yehyeong Lee Date: Fri Aug 21 17:06:20 2026 +0900 IB/isert: wait for deferred control PDU completions before releasing the connection [ Upstream commit a8fe3dfce8c0d8a76dc3d8486a5bff5feebe156f ] isert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and ISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns. The work item then runs isert_completion_put() -> isert_put_cmd(), which reads isert_conn->conn and takes conn->cmd_lock. Nothing orders that work item against teardown. isert_wait_conn() queues isert_release_work, which frees isert_conn, and iscsit_close_connection() frees the iscsit_conn right after it returns, so the queued work can run against freed memory. Count the deferred control PDU completions per connection and let isert_wait_conn() wait for them before the release work is queued. ISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs iscsit_logout_post_handler(), which ends up waiting for conn->conn_wait_comp, and that completion is only sent by iscsit_close_connection() after it has called iscsit_wait_conn(). Waiting for it here would deadlock. Its wait stays the existing isert_wait4logout(). The splat below is from a kernel with tracing printk()s and an msleep(200) injected into isert_do_control_comp() to widen the window: BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620 Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182 CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: isert_comp_wq isert_do_control_comp Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x3e/0x70 ? isert_put_cmd+0x53d/0x620 kasan_report+0xce/0x100 ? isert_put_cmd+0x53d/0x620 isert_put_cmd+0x53d/0x620 ? isert_completion_put+0x305/0x330 ? isert_do_control_comp+0x2ef/0x310 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 48: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x158/0x370 isert_cma_handler+0x1e3/0x2ae0 cma_cm_event_handler+0x3e/0x240 cma_ib_req_handler+0x17d9/0x4490 cm_process_work+0x41/0x330 cm_work_handler+0x5727/0xc160 process_one_work+0x633/0x1030 worker_thread+0x45b/0xd10 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 Freed by task 184: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x121/0x380 iscsit_close_connection+0x7cf/0x1e60 iscsit_take_action_for_connection_exit+0x1b6/0x360 iscsi_target_tx_thread+0x472/0x690 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260821080620.1694119-1-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2d9a59e05f59890afa23ca502bf4bd896c78f829 Author: Max Gurtovoy Date: Thu Apr 28 12:29:37 2022 +0300 scsi: target: iscsi: Rename iscsi_cmd to iscsit_cmd [ Upstream commit 66cd9d4ef74ae1ad459e3db3a3280182275c2ce9 ] The structure iscsi_cmd naming is used by the iSCSI initiator driver. Rename the target cmd to iscsit_cmd to have more readable code. Link: https://lore.kernel.org/r/20220428092939.36768-1-mgurtovoy@nvidia.com Reviewed-by: Mike Christie Signed-off-by: Max Gurtovoy Signed-off-by: Martin K. Petersen Stable-dep-of: a8fe3dfce8c0 ("IB/isert: wait for deferred control PDU completions before releasing the connection") Signed-off-by: Sasha Levin commit 6ea638a450a3ddbeef9b224b106402c42367d165 Author: Sebastian Andrzej Siewior Date: Sun Dec 20 21:36:35 2020 +0100 scsi: target: iscsi: Redo iscsit_check_session_usage_count() return code [ Upstream commit f88a10f80da9ed1ab1ba7496b70e9a0cdd8f7cf8 ] The return value of iscsit_check_session_usage_count() is only checked if it was not allowed to sleep. If it returns `2' then a timer is prepared. If it returns something else or if it was allowed to sleep then it is ignored. Let iscsit_check_session_usage_count() return true if it needs to arm the timer - otherwise false. This simplifies the code flow of the only caller. Link: https://lore.kernel.org/r/20201220203638.43615-4-bigeasy@linutronix.de Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Martin K. Petersen Stable-dep-of: a8fe3dfce8c0 ("IB/isert: wait for deferred control PDU completions before releasing the connection") Signed-off-by: Sasha Levin commit 341d4a97649dae1c70cc007b5c33b2394e6e49ad Author: Sebastian Andrzej Siewior Date: Sun Dec 20 21:36:34 2020 +0100 scsi: target: iscsi: Avoid in_interrupt() usage in iscsit_check_session_usage_count() [ Upstream commit efc9d73063c15f1aba8920b9f9ceaba4f3fb8ed9 ] iscsit_check_session_usage_count() uses in_interrupt() to find out if it is safe to invoke wait_for_completion(). The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. There is only one caller of iscsit_check_session_usage_count() which already has an argument indicating if it is safe to sleep. Extend iscsit_check_session_usage_count() by an argument indicating if it may sleep. Link: https://lore.kernel.org/r/20201220203638.43615-3-bigeasy@linutronix.de Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Martin K. Petersen Stable-dep-of: a8fe3dfce8c0 ("IB/isert: wait for deferred control PDU completions before releasing the connection") Signed-off-by: Sasha Levin commit 7d5ee7d4f91850d55e3332cca2f464a307089147 Author: Sebastian Andrzej Siewior Date: Sun Dec 20 21:36:33 2020 +0100 scsi: target: iscsi: Avoid in_interrupt() usage in iscsit_close_session() [ Upstream commit 433675486af4635416f8ece70b92b020a5b91005 ] iscsit_close_session() uses in_interrupt() to decide if it needs to check the return value of iscsit_check_session_usage_count() if it was not able to sleep. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. iscsit_close_session() has two callers: - iscsit_handle_time2retain_timeout() A timer_list callback. - iscsit_close_connection() Runs in preemptible context, acquires a mutex. Add an argument to iscsit_close_session() indicating if sleeping is possible. Link: https://lore.kernel.org/r/20201220203638.43615-2-bigeasy@linutronix.de Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Martin K. Petersen Stable-dep-of: a8fe3dfce8c0 ("IB/isert: wait for deferred control PDU completions before releasing the connection") Signed-off-by: Sasha Levin commit 198e4db9add54a50cce60a5d80b8f0ee5456b65a Author: Yehyeong Lee Date: Wed Aug 19 10:08:04 2026 +0900 IB/iser: reject a remote invalidation of an unregistered direction [ Upstream commit d85f0f0a7c85756fc992c70d869706f19dac9259 ] A write command whose data is sent entirely as immediate data is not registered. iser_reg_mem_fastreg() takes the DMA key path and leaves rdma_reg[ISER_DIR_OUT].desc at NULL, while iser_dma_map_task_data() has already set dir[ISER_DIR_OUT]. iser_check_remote_inv() looks at dir[] alone and hands the descriptor to iser_inv_desc(), which reads desc->sig_protected. A target that answers such a command with IB_WR_SEND_WITH_INV faults the initiator. Leaving those commands unregistered is deliberate. The same function already terminates the connection when a target sends a remote invalidation the initiator did not ask for. A target that invalidates a direction that was never registered is in the same class, so give it the same answer. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 UID: 0 PID: 40 Comm: kworker/u8:2 Not tainted 7.2.0-rc5-ISERHOST-gf5098b6bae76-dirty #3 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: rxe_wq do_work RIP: 0010:iser_task_rsp+0x6d6/0xec0 Code: 48 c1 ea 03 80 3c 02 00 0f 85 ba 06 00 00 48 8b 9b 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 20 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 76 06 00 00 80 7b 20 00 0f 84 3d 04 RSP: 0018:ffff88811b008db8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000001848 RDX: 0000000000000004 RSI: 1ffff11021587b12 RDI: 0000000000000020 RBP: ffff88810adc1ae4 R08: ffff888109b7f860 R09: ffffffff90a922c0 R10: ffff88810adc1a1c R11: 000000000000003c R12: ffff888109b7f800 R13: ffff88810adc1acc R14: ffff888109b7f820 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88818a676000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005afe2b CR3: 000000010af23005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: __ib_process_cq+0xe1/0x390 ib_poll_handler+0x6e/0x200 irq_poll_softirq+0x1df/0x480 ? clockevents_program_event+0x2ba/0x860 ? __pfx_irq_poll_softirq+0x10/0x10 handle_softirqs+0x18e/0x590 ? __pfx_handle_softirqs+0x10/0x10 ? __hrtimer_rearm_deferred+0x156/0x450 do_softirq+0x3b/0x60 __local_bh_enable_ip+0x61/0x70 __alloc_skb+0x732/0x890 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx___alloc_skb+0x10/0x10 ? _raw_read_unlock_irqrestore+0x16/0x50 rxe_init_packet+0x16b/0x4f0 prepare_ack_packet+0xb8/0x830 rxe_receiver+0x499/0x9980 ? __pfx_rxe_receiver+0x10/0x10 ? rxe_completer+0x29e5/0x38c0 ? hrtimer_start_range_ns_common+0x75f/0x1730 ? hrtimer_start_range_ns+0xa6/0x2c0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_rxe_receiver+0x10/0x10 do_work+0x144/0x470 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: 59caaed7a72a ("IB/iser: Support the remote invalidation exception") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819010804.641772-1-yhlee@isslab.korea.ac.kr Reviewed-by: Max Gurtovoy Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ae570253a8c7ee68f9b8db9a7b19d409fbb88c95 Author: Max Gurtovoy Date: Tue Mar 8 16:55:44 2022 +0200 IB/iser: Use iser_fr_desc as registration context [ Upstream commit ee4efeaea8837bb7018d188a9eb8837c7ff79561 ] After removing the FMR support in iSER, there is only one type of registration context. Replace the void pointer with the explicit structure for registration (struct iser_fr_desc). Link: https://lore.kernel.org/r/20220308145546.8372-3-mgurtovoy@nvidia.com Reviewed-by: Sergey Gorenko Signed-off-by: Max Gurtovoy Acked-by: Sagi Grimberg Signed-off-by: Jason Gunthorpe Stable-dep-of: d85f0f0a7c85 ("IB/iser: reject a remote invalidation of an unregistered direction") Signed-off-by: Sasha Levin commit 87b95a7993ec464aefe8d88bd291c81c8301e40e Author: Max Gurtovoy Date: Tue Mar 8 16:55:43 2022 +0200 IB/iser: Remove iser_reg_data_sg helper function [ Upstream commit 7f68d7493ff07a0ad63f63c4a1a4e0781cec0dd2 ] Open coding it makes the code more readable and simple. Link: https://lore.kernel.org/r/20220308145546.8372-2-mgurtovoy@nvidia.com Reviewed-by: Sergey Gorenko Signed-off-by: Max Gurtovoy Acked-by: Sagi Grimberg Signed-off-by: Jason Gunthorpe Stable-dep-of: d85f0f0a7c85 ("IB/iser: reject a remote invalidation of an unregistered direction") Signed-off-by: Sasha Levin commit 933fc0233b597a4fe878ce1505c90e8b8677542b Author: Max Gurtovoy Date: Wed Dec 15 15:57:21 2021 +0200 IB/iser: Align coding style across driver [ Upstream commit ca2770c65b56374374fa00c349883e67c16943de ] The following changes were made: 1. Align function signatures to 80 characters per line. 2. Remove tabs for variable assignment and use 1 space instead. 3. Don't compare to NULL in "if" clause. 4. Remove strange indentations. This will ease on the maintenance of the driver for the future. Link: https://lore.kernel.org/r/20211215135721.3662-7-mgurtovoy@nvidia.com Signed-off-by: Max Gurtovoy Signed-off-by: Jason Gunthorpe Stable-dep-of: d85f0f0a7c85 ("IB/iser: reject a remote invalidation of an unregistered direction") Signed-off-by: Sasha Levin commit 6e3b55823da8ef0d99621efb422cc29f50d7f280 Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate [ Upstream commit 70f4b78d560e592cbf3325b162424737d032fc1d ] dvfs_get_idx() may return an out-of-range index if the SCP firmware is buggy or returns a stale value. Only negative indexes were rejected, so a large index walked past info->opps and could treat garbage as a clock rate (KASAN OOB / wrong frequency to consumers). The missing upper bound dates back to the original SCPI clock driver. Treat indexes >= opp count as invalid and return 0, same as idx < 0. Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/04f9ab766e07.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit e9887eeaa138c6b5697af3d2f7c71dc82407b154 Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS [ Upstream commit 32471d84a487c7fd74532bc96be56f8028cf4a3f ] scpi_dvfs_get_info() already rejected a zero opp_count, but still trusted any larger value from the SCP firmware. The shared-memory reply only holds MAX_DVFS_OPPS entries in buf.opps[]; a bigger count over-reads that array and then sizes the allocated OPP table incorrectly (garbage OPPs / OOB). The missing upper bound dates back to the original SCPI DVFS support. Reject zero and out-of-range counts in one check and return -EINVAL. Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/022802f0b38f.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f11e09fe2fc3a11ccdf8f932b68181b0bb1d2078 Author: Guoqing Jiang Date: Thu Aug 27 20:55:53 2026 +0800 RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept [ Upstream commit 32cd87f54dd1070020e664ccb0312a9f0fea79b4 ] We need to clear cep before release state_lock as siw_qp_llp_close and siw_qp_modify->siw_qp_llp_close did. Otherwise if siw_qp_modify() fails in siw_accept(), the QP's state_lock is released before the error path cleanup. A concurrent ibv_modify_qp() transitioning the QP to ERROR can race in this window: siw_accept() ibv_modify_qp(ERROR) ---------------------- ---------------------- siw_qp_modify() fails up_write(&qp->state_lock) down_write(&qp->state_lock) nextstate_from_idle(): if (qp->cep) siw_cep_put(qp->cep) <- frees cep qp->cep = NULL goto error cep->qp = NULL <- UAF Clear qp->cep and drop the association reference taken by siw_cep_get(), all under the write lock held from the initial down_write(&qp->state_lock). Thread B therefore sees qp->cep == NULL, skips its own put, and cannot free the cep before siw_accept() is done with it. Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Reported-by: Shuangpeng Bai Link: https://lore.kernel.org/linux-rdma/d6fbe475-a5c2-f975-99b0-a0bd6b6d10e8@linux.dev/T/#m5876c1ff2de8686a9a1173b8f1aa0ff5363a785c Signed-off-by: Guoqing Jiang Link: https://patch.msgid.link/20260827125553.12831-1-guoqing.jiang@linux.dev Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5b323ed38a78d07f745298011d5d6a2ff900cc19 Author: Guoqing Jiang Date: Mon Nov 13 19:57:21 2023 +0800 RDMA/siw: Cleanup siw_accept [ Upstream commit 77b59bd932a026b64303d313d966decb0e9225fa ] With the initialization of rv and the two added label, we can simplifiy code a bit. Acked-by: Bernard Metzler Signed-off-by: Guoqing Jiang Link: https://lore.kernel.org/r/20231113115726.12762-13-guoqing.jiang@linux.dev Signed-off-by: Leon Romanovsky Stable-dep-of: 32cd87f54dd1 ("RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept") Signed-off-by: Sasha Levin commit 3f2ad501541824fdb5b0dbdf30158b62b40de46a Author: Guoqing Jiang Date: Mon Nov 13 19:57:19 2023 +0800 RDMA/siw: Introduce siw_cep_set_free_and_put [ Upstream commit b5c91543204c345f1b28af573854c4b7e699cc91 ] Add the helper which can be used in some places. Acked-by: Bernard Metzler Signed-off-by: Guoqing Jiang Link: https://lore.kernel.org/r/20231113115726.12762-11-guoqing.jiang@linux.dev Signed-off-by: Leon Romanovsky Stable-dep-of: 32cd87f54dd1 ("RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept") Signed-off-by: Sasha Levin commit 3e1b61fef17402e2b1dedeb8c00ccb92f4545ab5 Author: Pengpeng Hou Date: Sun Aug 30 22:22:44 2026 +0800 ARM: socfpga: select the PL310 erratum 753970 workaround [ Upstream commit cfc1e9a543e3589ba200795b6e7fd8ef4314efdf ] ARCH_INTEL_SOCFPGA selects CACHE_L2X0 and several PL310 erratum workarounds. The 753970 workaround is still conditioned on PL310, but that Kconfig symbol no longer exists, so this one selection is always disabled. Select PL310_ERRATA_753970 directly, consistently with the other PL310 workarounds required by the platform. Fixes: fbc125afdc50 ("ARM: socfpga: Turn on ARM errata for L2 cache") Signed-off-by: Pengpeng Hou Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 494f2bee9d8d0ebcfa249ac41bed7fed26d119b4 Author: Kyle Zeng Date: Tue Aug 4 06:10:37 2026 +0000 xfrm: fix compat ALLOCSPI request use-after-free [ Upstream commit d1ebd9081879fd9ae9c8fb7e8928f19cc88ae320 ] xfrm_state_netlink() builds the ALLOCSPI response with dump_one_state(), which already calls alloc_compat() with the response skb and header. xfrm_alloc_userspi() then calls alloc_compat() again, but passes the original request skb and its header. For a compat request, the translator therefore interprets the 228-byte compat xfrm_userspi_info as the 232-byte native layout and reads four bytes past the declared payload. It also publishes the translated child through the request's frag_list. A multicast clone of the request shares skb_shared_info and can observe that child. xfrm_user_rcv_msg() frees it after the request handler returns, racing a compat receiver which may still be copying from it and resulting in a use-after-free. Remove the redundant conversion. The response keeps its correct compat translation from dump_one_state(), and no child is attached to the inbound request. Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator") Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit c48308ad35514c150a88be5c77b02d2c29a1e968 Author: Sabrina Dubroca Date: Mon Mar 9 11:32:43 2026 +0100 xfrm: avoid RCU warnings around the per-netns netlink socket [ Upstream commit d87f8bc47fbf012a7f115e311d0603d97e47c34c ] net->xfrm.nlsk is used in 2 types of contexts: - fully under RCU, with rcu_read_lock + rcu_dereference and a NULL check - in the netlink handlers, with requests coming from a userspace socket In the 2nd case, net->xfrm.nlsk is guaranteed to stay non-NULL and the object is alive, since we can't enter the netns destruction path while the user socket holds a reference on the netns. After adding the __rcu annotation to netns_xfrm.nlsk (which silences sparse warnings in the RCU users and __net_init code), we need to tell sparse that the 2nd case is safe. Add a helper for that. Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Stable-dep-of: d1ebd9081879 ("xfrm: fix compat ALLOCSPI request use-after-free") Signed-off-by: Sasha Levin commit 7f9a05c930d3f7a69b20a00acb34a1a1a7b0ab28 Author: Sabrina Dubroca Date: Wed Sep 14 19:04:02 2022 +0200 xfrm: add extack to verify_one_alg, verify_auth_trunc, verify_aead [ Upstream commit 1fc8fde553917bca7c9b65fafb045a2a5c97e683 ] Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Stable-dep-of: d1ebd9081879 ("xfrm: fix compat ALLOCSPI request use-after-free") Signed-off-by: Sasha Levin commit 7a7036bb80c392db48a72161dd25822c53b8b64f Author: Sabrina Dubroca Date: Wed Sep 14 19:04:00 2022 +0200 xfrm: add extack support to verify_newsa_info [ Upstream commit 6999aae17a7b66c56e6cc8e05b3cd51718c3bfe3 ] Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Stable-dep-of: d1ebd9081879 ("xfrm: fix compat ALLOCSPI request use-after-free") Signed-off-by: Sasha Levin commit 18a6a0e5ee95e4955e6d880d7d1446f1899a0f06 Author: Sabrina Dubroca Date: Tue Aug 30 16:23:12 2022 +0200 xfrm: add extack to verify_sec_ctx_len [ Upstream commit 08a717e4803798e066aa6b69ebf69da9fc8e1758 ] Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Stable-dep-of: d1ebd9081879 ("xfrm: fix compat ALLOCSPI request use-after-free") Signed-off-by: Sasha Levin commit 3f7778b7513c78a37b119b4dd813a6287b78fd95 Author: Sabrina Dubroca Date: Tue Aug 30 16:23:07 2022 +0200 xfrm: propagate extack to all netlink doit handlers [ Upstream commit 3bec6c3e83b5c125ff35e3dae3127c8d62046a1d ] xfrm_user_rcv_msg() already handles extack, we just need to pass it down. Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Stable-dep-of: d1ebd9081879 ("xfrm: fix compat ALLOCSPI request use-after-free") Signed-off-by: Sasha Levin commit b7cbe148f15294a589f31a75d7f4962505dc22af Author: Ido Schimmel Date: Thu Jun 11 18:46:04 2026 +0300 ipv6: Honor oif when choosing nexthop for locally generated traffic [ Upstream commit d25e7e9d8a6c1e2afb854613e417c6aa1a28ce6f ] Commit 741a11d9e410 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set") made the kernel honor the oif parameter when specified as part of output route lookup: # ip route add 2001:db8:1::/64 dev dummy1 # ip route add ::/0 dev dummy2 # ip route get 2001:db8:1::1 oif dummy2 fibmatch default dev dummy2 metric 1024 pref medium Due to regression reports, the behavior was partially reverted in commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE flag if saddr set") to only honor the oif if source address is not specified: # ip route get 2001:db8:1::1 from 2001:db8:2::1 oif dummy2 fibmatch 2001:db8:1::/64 dev dummy1 metric 1024 pref medium That is, when source address is specified, the kernel will choose the most specific route even if its nexthop device does not match the specified oif. This creates a problem for multipath routes. After looking up a route, when source address is not specified, the kernel will choose a nexthop whose nexthop device matches the specified oif: # sysctl -wq net.ipv6.conf.all.forwarding=1 # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2 # for i in {1..100}; do ip route get 2001:db8:10::${i} oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 But will disregard the oif when source address is specified despite the fact that a matching nexthop exists: # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 53 dummy1 47 dummy2 This behavior differs from IPv4: # ip address add 192.0.2.1/32 dev lo # ip route add 198.51.100.0/24 nexthop via inet6 fe80::1 dev dummy1 nexthop via inet6 fe80::2 dev dummy2 # for i in {1..100}; do ip route get 198.51.100.${i} from 192.0.2.1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 What happens is that fib6_table_lookup() returns a route with a matching nexthop device (assuming it exists): # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 But it is later overwritten during path selection in fib6_select_path() which instead chooses a nexthop according to the calculated hash. Solve this by telling fib6_select_path() to skip path selection if we have an oif match during output route lookup (iif being LOOPBACK_IFINDEX). Behavior after the change: # sysctl -wq net.ipv6.conf.all.forwarding=1 # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2 # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 Note that enabling forwarding is only needed because we did not add neighbor entries for the gateway addresses. When forwarding is disabled and CONFIG_IPV6_ROUTER_PREF is not enabled in kernel config, the kernel will treat non-existing neighbor entries as errors and perform round-robin between the nexthops: # sysctl -wq net.ipv6.conf.all.forwarding=0 # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 50 dummy1 50 dummy2 Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260611154605.992528-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 777ea42d4bac5d628071330b74f9378d42544437 Author: Ido Schimmel Date: Thu Jun 11 18:46:03 2026 +0300 ipv6: Select best matching nexthop object in fib6_table_lookup() [ Upstream commit 484bb9d164df397a53e0f533b262b27b1590efcb ] Currently, when using multipath routes without nexthop objects, fib6_table_lookup() selects the nexthop with the highest score. This means that when both a source address and an oif are specified, the nexthop that is chosen is the one that matches in terms of oif: # sysctl -wq net.ipv6.conf.all.forwarding=1 # ip address add 2001:db8:2::1/64 dev lo # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy1; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 When using nexthop objects, fib6_table_lookup() selects the first matching nexthop and not necessarily the one with the highest score: # ip nexthop add id 1 via fe80::1 dev dummy1 # ip nexthop add id 2 via fe80::2 dev dummy2 # ip nexthop add id 3 group 1/2 # ip route add 2001:db8:20::/64 nhid 3 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy1; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 This is not very significant right now because the nexthop is later overwritten during path selection in fib6_select_path(). However, the next patch is going to skip path selection when we have an oif match during output route lookup. As a preparation for this change, align the nexthop object behavior with the legacy one and make sure that fib6_table_lookup() always selects the best matching nexthop. Do that by always returning 0 from rt6_nh_find_match() in order not to terminate the loop in nexthop_for_each_fib6_nh() and storing in arg->nh the best matching nexthop so far. Behavior after the change: # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy1; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260611154605.992528-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 058423ef3c4fdfae2605bed8eb4ec77ebbc64e3f Author: Arash Golgol Date: Sun May 10 07:04:23 2026 +0330 media: video-i2c: fix buffer queue ordering [ Upstream commit bc4574c265ed738849e46d942617100580fcedd2 ] Queued buffers are added to the tail of vid_cap_active in buffer_queue(), but the capture kthread also retrieves buffers from the tail of the list. This makes the queue behave as LIFO instead of FIFO when multiple buffers are queued. Fix this by retrieving buffers from the head of the list. Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c2c966024272c1a9df5b511a67532448c0d5115e Author: Sasha Levin Date: Sun Sep 20 11:16:36 2026 -0400 Revert "perf cs-etm: Flush thread stacks after decoder reset" This reverts commit e7e168699270235880344e3a0c9b8ce5c947ff3a. Signed-off-by: Sasha Levin commit ab71d27e471cd2901a52c887d4a862c494102039 Author: Sasha Levin Date: Sun Sep 20 11:16:36 2026 -0400 Revert "perf cs-etm: Avoid truncating AUX buffer sizes to int" This reverts commit 23893444447675e4e0701e24eb31163c8540438d. Signed-off-by: Sasha Levin commit 9cc0170ae646876aa5de2f0cad3066ce53e86f27 Author: Guangguan Wang Date: Sun Sep 20 13:16:00 2026 +0800 net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg commit 7863c9f3d24ba49dbead7e03dfbe40deb5888fdf upstream. When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them. Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal") Signed-off-by: Guangguan Wang Reviewed-by: Wen Gu Reviewed-by: D. Wythe Signed-off-by: David S. Miller [ jcao: drop the af_smc.c hunk, smc_find_rdma_v2_device_serv() came with SMC-Rv2 in e49300a6bf62 (v5.16); take SMC_CLC_MAX_UEID from fa0866625543 (v5.16); SMC_MAX_ISM_DEVS is the pre-b40584d14570 name of SMCD_CLC_MAX_V2_GID_ENTRIES ] Signed-off-by: Junjie Cao Signed-off-by: Sasha Levin commit 35da53027c1f2efdd7d0177dc00584134204761a Author: Guangguan Wang Date: Sun Sep 20 13:14:02 2026 +0800 net/smc: check smcd_v2_ext_offset when receiving proposal msg commit 9ab332deb671d8f7e66d82a2ff2b3f715bc3a4ad upstream. When receiving proposal msg in server, the field smcd_v2_ext_offset in proposal msg is from the remote client and can not be fully trusted. Once the value of smcd_v2_ext_offset exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the value of smcd_v2_ext_offset before using it. Fixes: 5c21c4ccafe8 ("net/smc: determine accepted ISM devices") Signed-off-by: Guangguan Wang Reviewed-by: Wen Gu Reviewed-by: D. Wythe Signed-off-by: David S. Miller [ jcao: drop the af_smc.c hunk, the !smcd_v2_ext test already there covers it; result matches the 5.15.y backport a36364d8d4fab ] Signed-off-by: Junjie Cao Signed-off-by: Sasha Levin commit 090bf120a1e94cb41db786851f14c09933cac66a Author: Jens Axboe Date: Tue Sep 1 19:39:46 2026 +0200 sunvdc: fix -EIO issue due to lack of retries [ Upstream commit 5067d4ba713961d8ccea1e06cd4c453793f3121e ] John reports that since commit: a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") users of Linux inside Solaris ldom see occasional -EIO errors because the request send loop now times out. The current loop does 10 retries, and inside vio_ldc_send() a further 1000 1usec retries are done as well. Even with 10.5 msec of busy loop retries that's apparently not enough to always succeed. Rather than introduce continued busy looping, requeue the request and have the delayed queue kicking retry the request after another 10ms. This obviously isn't ideal, but there's seemingly no way to wait for this type of event. And if 10ms of busy looping was not enough to make progress, then presumably this is an edge condition and we just need to guarantee to make forward progress at some later point in time. That's more suitably done through letting the CPU tend to other work, rather than sitting in a tight loop retrying. [stian: rebased on top of the cookie-unmap fix, without which every requeued attempt leaks LDC map table entries; tested on an UltraSPARC T4 LDOM where the vdc_tx_trigger failure condition was reproduced and absorbed by the requeue with no I/O error] Reported-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/all/20251006100226.4246-2-glaubitz@physik.fu-berlin.de/ Link: https://lore.kernel.org/all/418310b3-2b77-4534-b2fd-27dcc11e333c@kernel.dk/ Signed-off-by: Stian Halseth Link: https://patch.msgid.link/20260901173947.3292110-3-stian@itx.no Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 844808f3ec656ec6aa8b9a52db61d1833097f2bc Author: Russell King (Oracle) Date: Thu Sep 17 10:30:56 2026 +0800 ARM: ensure interrupts are enabled in __do_user_fault() [ Upstream commit 59e4f3b45b96a24fc9b7a89e5f8a2168b30f95af ] __do_user_fault() may be called from fault handling paths where the interrupts are enabled or disabled. E.g. do_page_fault() calls this with interrupts enabled, whereas do_sect_fault()->do_bad_area() will call this with interrupts disabled. Since this is a userspace fault, we know that interrupts were enabled in the parent context, so call local_irq_enable() here to give a consistent interrupt state. This is necessary for force_sig_info() when PREEMPT_RT is enabled. Reported-by: Yadi.hu Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin Signed-off-by: Sasha Levin commit ca8d53a2d0e39f0a4e72def681d83187cd34a731 Author: Russell King (Oracle) Date: Thu Sep 17 10:30:55 2026 +0800 ARM: fix branch predictor hardening [ Upstream commit fd2dee1c6e2256f726ba33fd3083a7be0efc80d3 ] __do_user_fault() may be called with indeterminent interrupt enable state, which means we may be preemptive at this point. This causes problems when calling harden_branch_predictor(). For example, when called from a data abort, do_alignment_fault()->do_bad_area(). Move harden_branch_predictor() out of __do_user_fault() and into the calling contexts. Moving it into do_kernel_address_page_fault(), we can be sure that interrupts will be disabled here. Converting do_translation_fault() to use do_kernel_address_page_fault() rather than do_bad_area() means that we keep branch predictor handling for translation faults. Interrupts will also be disabled at this call site. do_sect_fault() needs special handling, so detect user mode accesses to kernel-addresses, and add an explicit call to branch predictor hardening. Finally, add branch predictor hardening to do_alignment() for the faulting case (user mode accessing kernel addresses) before interrupts are enabled. This should cover all cases where harden_branch_predictor() is called, ensuring that it is always has interrupts disabled, also ensuring that it is called early in each call path. [ Xie Yuanbin: At the upstream, the following patches are a patch set: 1. commit dea20281ac8822661576 ("ARM: group is_permission_fault() with is_translation_fault()") 2. commit 40b466db1dffb41f0529 ("ARM: allow __do_kernel_fault() to report execution of memory faults") 3. commit 7733bc7d299d682f2723 ("ARM: fix hash_name() fault") 4. commit fd2dee1c6e2256f726ba ("ARM: fix branch predictor hardening") patch 1. and 2. is unneeded for 5.10.y and 5.15.y . This patch backports patch 4. and simply adapts to the context differences. ] Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin Signed-off-by: Sasha Levin commit 20396a5f292ae73ee6be50ba0492d889351b1069 Author: Russell King (Oracle) Date: Thu Sep 17 10:30:54 2026 +0800 ARM: fix hash_name() fault [ Upstream commit 7733bc7d299d682f2723dc38fc7f370b9bf973e9 ] Zizhi Wo reports: "During the execution of hash_name()->load_unaligned_zeropad(), a potential memory access beyond the PAGE boundary may occur. For example, when the filename length is near the PAGE_SIZE boundary. This triggers a page fault, which leads to a call to do_page_fault()->mmap_read_trylock(). If we can't acquire the lock, we have to fall back to the mmap_read_lock() path, which calls might_sleep(). This breaks RCU semantics because path lookup occurs under an RCU read-side critical section." This is seen with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_KFENCE=y. Kernel addresses (with the exception of the vectors/kuser helper page) do not have VMAs associated with them. If the vectors/kuser helper page faults, then there are two possibilities: 1. if the fault happened while in kernel mode, then we're basically dead, because the CPU won't be able to vector through this page to handle the fault. 2. if the fault happened while in user mode, that means the page was protected from user access, and we want to fault anyway. Thus, we can handle kernel addresses from any context entirely separately without going anywhere near the mmap lock. This gives us an entirely non-sleeping path for all kernel mode kernel address faults. As we handle the kernel address faults before interrupts are enabled, this change has the side effect of improving the branch predictor hardening, but does not completely solve the issue. [ Xie Yuanbin: At the upstream, the following patches are a patch set: 1. commit dea20281ac8822661576 ("ARM: group is_permission_fault() with is_translation_fault()") 2. commit 40b466db1dffb41f0529 ("ARM: allow __do_kernel_fault() to report execution of memory faults") 3. commit 7733bc7d299d682f2723 ("ARM: fix hash_name() fault") 4. commit fd2dee1c6e2256f726ba ("ARM: fix branch predictor hardening") patch 1. and 2. is unneeded for 5.10.y and 5.15.y . This patch backports patch 3. and simply adapts to the context differences. ] Reported-by: Zizhi Wo Reported-by: Xie Yuanbin Link: https://lore.kernel.org/r/20251126090505.3057219-1-wozizhi@huaweicloud.com Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin Signed-off-by: Sasha Levin commit 94f0bb7a3167fa3d1e891a182a7473df5d2b380e Author: Luiz Augusto von Dentz Date: Wed Sep 16 21:34:54 2026 +0200 Bluetooth: L2CAP: Fix deadlock [ Upstream commit f1a8f402f13f94263cf349216c257b2985100927 ] This fixes the following deadlock introduced by 39a92a55be13 ("bluetooth/l2cap: sync sock recv cb and release") ============================================ WARNING: possible recursive locking detected 6.10.0-rc3-g4029dba6b6f1 #6823 Not tainted -------------------------------------------- kworker/u5:0/35 is trying to acquire lock: ffff888002ec2510 (&chan->lock#2/1){+.+.}-{3:3}, at: l2cap_sock_recv_cb+0x44/0x1e0 but task is already holding lock: ffff888002ec2510 (&chan->lock#2/1){+.+.}-{3:3}, at: l2cap_get_chan_by_scid+0xaf/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&chan->lock#2/1); lock(&chan->lock#2/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/u5:0/35: #0: ffff888002b8a940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work+0x750/0x930 #1: ffff888002c67dd0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work+0x44e/0x930 #2: ffff888002ec2510 (&chan->lock#2/1){+.+.}-{3:3}, at: l2cap_get_chan_by_scid+0xaf/0xd0 To fix the original problem this introduces l2cap_chan_lock at l2cap_conless_channel to ensure that l2cap_sock_recv_cb is called with chan->lock held. Fixes: 89e856e124f9 ("bluetooth/l2cap: sync sock recv cb and release") Signed-off-by: Luiz Augusto von Dentz [ Karl Mehltretter: only the l2cap_core.c and l2cap_sock.c hunks apply to this tree. hci_sync.c and hci_sync.h do not exist here, and the hci_core.c change is an unrelated conversion of hci_dev_cmd() off the old hci_request API. The changes to both L2CAP files apply unmodified. The lock this adds to l2cap_conless_channel() is also the one that commit c531e63871c0 ("Bluetooth: l2cap: always unlock channel in l2cap_conless_channel()") was backported without, so it additionally pairs the l2cap_chan_unlock() that function currently calls on a mutex it never acquired. ] Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Sasha Levin commit 59a3ccd749b2550392ee531b4d727022eae4c89f Author: Sasha Levin Date: Thu Sep 17 15:22:56 2026 -0400 Reapply "bluetooth/l2cap: sync sock recv cb and release" [ Upstream commit 89e856e124f9ae548572c56b1b70c2255705f8fe ] This reverts commit 6ecdf922fb6bf92b6942edfa3f1aa874f1fd7c4d. Signed-off-by: Sasha Levin commit 76a9234cb66479e9d02b15fd0f3e349cb2320279 Author: Darrick J. Wong Date: Wed Sep 16 16:26:27 2026 +0200 iomap: iomap: fix memory corruption when recording errors during writeback [ Upstream commit 3d5f3ba1ac28059bdf7000cae2403e4e984308d2 ] Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: 1 PID: 122167 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 do_writepages+0x90/0x1c4 __writeback_single_inode+0x4c/0x4ac Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 writeback_sb_inodes+0x214/0x4ac wb_writeback+0xf4/0x3b0 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) wb_workfn+0xfc/0x580 process_one_work+0x1e8/0x480 pc : 000003fd6d7df200 worker_thread+0x78/0x430 This crash is a result of iomap_writepage_map encountering some sort of error during writeback and wanting to set that error code in the file mapping so that fsync will report it. Unfortunately, the code dereferences folio->mapping after unlocking the folio, which means that another thread could have removed the page from the page cache (writeback doesn't hold the invalidation lock) and give it to somebody else. At best we crash the system like above; at worst, we corrupt memory or set an error on some other unsuspecting file while failing to record the problems with *this* file. Regardless, fix the problem by reporting the error to the inode mapping. NOTE: Commit 598ecfbaa742 lifted the XFS writeback code to iomap, so this fix should be backported to XFS in the 4.6-5.4 kernels in addition to iomap in the 5.5-5.19 kernels. Fixes: e735c0079465 ("iomap: Convert iomap_add_to_ioend() to take a folio") # 5.17 onward Fixes: 598ecfbaa742 ("iomap: lift the xfs writeback code to iomap") # 5.5-5.16, needs backporting Fixes: 150d5be09ce4 ("xfs: remove xfs_cancel_ioend") # 4.6-5.4, needs backporting Signed-off-by: Darrick J. Wong Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit 2f8c4d57b312912f6807ced9c47095c2a233bbaa Author: Paolo Abeni Date: Sat Sep 19 22:40:06 2026 +0200 mptcp: close race between scheduler and state change commit 42064de57fb83231fcc89663a94885f228a1ee53 upstream. The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario. Fixes: c886d70286bf ("mptcp: do not queue data on closed subflows") Cc: stable@vger.kernel.org Reported-by: Shardul Bankar Reported-by: Xinyang Ge Closes: https://lore.kernel.org/20260525194828.1137119-1-shardul.b@mpiricsoftware.com Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-2-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski [ Note: moved the mss_now check in previous places before commit d9ca1de8c0cd ("mptcp: move page frag allocation in mptcp_sendmsg()") which is not in this version. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 6d669c740933124eae3df8cfc15995af9bcc6aba Author: Paolo Abeni Date: Sat Sep 19 22:40:05 2026 +0200 mptcp: avoid unneeded actions on subflow reset commit 2b0f561f21b27c40c91ea4975268a06092bd7e9c upstream. Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it. Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption") Cc: stable@vger.kernel.org Reported-by: Xinyang Ge Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski [ Note: conflict in protocol.c, because commit e0ca4057e0ec ("mptcp: micro-optimize __mptcp_move_skb()") is not in this version, and is part of a consequent rx path refactor. The conflict is in the context, and is easy to resolve, "done = true" can be moved along without consequences. Also, the context is slightly different because there is no DEBUG_NET_WARN_ON_ONCE in this version, see the backport commit 12c1676d598e ("mptcp: handle consistently DSS corruption"). Also a conflict in protocol.h, because __unused is at a different number. Decrement the one from this version and add the new flag above. The context is also a bit different with data_avail being an enum, but that's without consequences here. Also a conflict in subflow.c, because commit 71154bbe4942 ("mptcp: fallback earlier on simult connection") was not needed in this version, and cause conflicts in the context, but that's without consequences here. Also, a conflict in the context, because commit 81c1d0290160 ("mptcp: consolidate fallback and non fallback state machine") was not needed in this version. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 82d16777df33a805be6892bcf5c06b63dda9d437 Author: Florian Westphal Date: Sat Sep 19 22:40:04 2026 +0200 mptcp: hold mptcp socket before calling tcp_done commit ab82e996a1fa1b9ae514fa357d9ce8df62321157 upstream. When processing options from tcp reset path its possible that tcp_done(ssk) drops the last reference on the mptcp socket which results in use-after-free. Reviewed-by: Matthieu Baerts Signed-off-by: Florian Westphal Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Stable-dep-of: 2b0f561f21b2 ("mptcp: avoid unneeded actions on subflow reset") [ Conflicts in subflow.c, because commit 3ba14528684f ("mptcp: avoid setting TCP_CLOSE state twice") has already been backported and also had the same conflict: this commit here should have been backported first. Fixed now! ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 0b0b2dbb75cdf171558ebf15c78544bdb1a666bb Author: Eric Biggers Date: Sat Aug 15 13:57:50 2026 -0700 netfilter: nft_set_pipapo_avx2: add missing vzeroupper commit 55dd20f0f4b1be5c9c8a0275d8d763c86563eac2 upstream. Since pipapo_get_avx2() uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 19588f78db582ba4c47b4001bb27f39bb19dc432 Author: Eric Biggers Date: Mon Jun 15 15:41:29 2026 -0700 crypto: sun8i-ce - Remove crypto_rng interface commit 011556f71d094da61379ae3672692cae2795304e upstream. Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable. Fixes: 5eb7e9468884 ("crypto: sun8i-ce - Add support for the PRNG") Cc: stable@vger.kernel.org Cc: Corentin Labbe Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9127d2a88c1795ddc4ba7687fea01cab1908fae1 Author: Eric Biggers Date: Mon Jun 15 15:41:30 2026 -0700 crypto: sun8i-ss - Remove crypto_rng interface commit a78446ee6fae86ac8733f120e3ffce2e5d9384f5 upstream. Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable. Fixes: ac2614d721de ("crypto: sun8i-ss - Add support for the PRNG") Cc: stable@vger.kernel.org Cc: Corentin Labbe Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0ee628a58d83e571f36ec9f07624d6845e420c50 Author: Xuanqiang Luo Date: Wed Jul 22 16:38:58 2026 +0800 fou: Fix use-after-free in fou_create() commit b14361aca6350ff7907b0e9903c7b94dc7d5d4a0 upstream. fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release(). Fixes: 23461551c006 ("fou: Support for foo-over-udp RX path") Suggested-by: Kuniyuki Iwashima Link: https://lore.kernel.org/netdev/20260502031401.3557229-12-kuniyu@google.com/ Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260722083858.182506-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Dmitriy Okunev Signed-off-by: Greg Kroah-Hartman commit 51cc5e756cec6071ffc620076aebcf5bae936668 Author: Weiming Shi Date: Thu May 14 05:38:08 2026 -0700 net: appletalk: fix NULL pointer dereference in aarp_send_ddp() commit 9e7f36ab5b7bf68463faa5f7b926fea8f35597bb upstream. aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260514123806.3085961-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 856dffcc097b3d8ed45a643ebda07cb92968cb33 Author: Weiming Shi Date: Wed May 6 01:55:11 2026 +0800 i2c: smbus: reject oversized block transfers in the common path commit 3051cd060fa496df42954291fa2306ed2eab4ecc upstream. The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN. Fixes: 8a325997d95d ("i2c: Add message transfer tracepoints for SMBUS [ver #2]") Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit cbc1f954ce67d739d41d1f0757d29850353ebb6a Author: Kazuki Hanai Date: Wed Sep 16 21:26:36 2026 +0900 ALSA: us122l: Prevent write upgrades for read mappings [ Upstream commit 71c610aeb1770302ac9c9e0b9a4ecd37f1311928 ] The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Link: https://patch.msgid.link/20260908110053.2950767-1-hnkz.64@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 638e8fe3563a82f298fe537a28d5342a97278cf1 Author: Eric Dumazet Date: Wed Sep 16 17:12:32 2026 +0900 ipv6: mcast: extend RCU protection in igmp6_send() [ Upstream commit 087c1faa594fa07a66933d750c0b2610aa1a2946 ] igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. Fixes: b8ad0cbc58f7 ("[NETNS][IPV6] mcast - handle several network namespace") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250207135841.1948589-9-edumazet@google.com Signed-off-by: Jakub Kicinski [ use IP6_UPD_PO_STATS(net, idev, IPSTATS_MIB_OUT, full_len) instead of upstream's IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTPKTS). Older LTS kernels do not have commit b4a11b2033b7 ("net: fix IPSTATS_MIB_OUTPKGS increment in OutForwDatagrams"), so the legacy byte-based counter logic must be preserved. ] Signed-off-by: Shun Ota Signed-off-by: Sasha Levin commit c97fa2c7ada82d4cac1c6c00643238dc4c462f15 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:08 2026 +0200 mptcp: syncookies: remember the request backup flag commit b76c0e28b392620dfbaf92cdeedbf115820b44cb upstream. Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both. Fixes: efd340bf3d77 ("mptcp: distinguish rcv vs sent backup flag in requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-3-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e40641638743b4b848d5ed78a0565afffc359d8e Author: Joe Damato Date: Tue Sep 1 18:56:48 2026 -0700 bnxt_en: Propagate RX ring init failures in bnxt_init_nic() commit 8e6a850c0746bb4be167aedf1ee57469fcda09a9 upstream. bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-6-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 52fc97cbc3ba118aad84e7c001bf02ebe8496f70 Author: Joe Damato Date: Tue Sep 1 18:56:47 2026 -0700 bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() commit 961e2a17c5e3559b3f8654d2daabdd25a42e770a upstream. bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed. Fixes: 8fbf58e17dce ("bnxt_en: Implement RX ring reset in response to buffer errors.") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-5-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 49dbed49360e1fb64226f2f8d3f15383695ea8ea Author: Haotian Zhang Date: Tue Sep 1 10:23:09 2026 +0800 media: v4l2-h264: Fix memcmp() size in B1 reference list comparison commit 10e59fbdef13597836bd6459095caa02c80af3d7 upstream. In v4l2_h264_build_b_ref_lists(), the B0/B1 list equality check passes the entry count builder->num_valid to memcmp() instead of a byte size. Since struct v4l2_h264_reference is two bytes (fields and index), only half of each list is compared, so distinct lists can be wrongly treated as equal and trigger an incorrect swap(b1_reflist[0], b1_reflist[1]). Change the memcmp() size argument to sizeof(b1_reflist[0]) * builder->num_valid so that the full byte length of both reference lists is compared. Fixes: 624922a2739b ("media: v4l2-core: Add helpers to build the H264 P/B0/B1 reflists") Suggested-by: Nicolas Dufresne Cc: stable@vger.kernel.org Signed-off-by: Haotian Zhang Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a4a7931555db0b996004b849d2d363d4a56abf24 Author: Michael Bommarito Date: Tue Jun 16 22:19:00 2026 -0400 media: hevc: add bounded tile-count helpers commit 592dd4f8442a13bed6e946d73d3164ba38b33bbd upstream. The stateless HEVC decoders compute the number of tile columns and rows from num_tile_columns_minus1 / num_tile_rows_minus1 and clamp it to the column_width_minus1[] / row_height_minus1[] capacity before using it as a loop bound. Add shared helpers in a new so the rkvdec and hantro drivers do not each open-code the min_t() clamp. Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-8 Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Cc: stable@vger.kernel.org Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d8d01f050a20c6c269d52fd24f7652c91ffdf584 Author: Vishnu Razdan Date: Mon Aug 24 23:58:00 2026 -0700 hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS commit 6d760f8b41aed74de4402440e4db663d261478bd upstream. Some hwmon alarms fall back to STATUS_WORD summary bits when no individual limit alarm is available. On PMBus 1.2 and newer devices, pmbus_get_boolean() acknowledges these alarms with the same byte-data write used for detailed status registers. For example, PB_STATUS_INPUT is 0x2000, so it is truncated to zero when passed to _pmbus_write_byte_data(). The resulting write cannot acknowledge the input alarm. PMBus 1.3 Part II, sections 10.2.4 and 10.2.5, excludes ordinary STATUS_BYTE and STATUS_WORD summary bits from individual clearing. Their summary bits clear when the underlying status bits clear, so changing this to a word-data write would not fix the generic input alarm either. Use the existing page CLEAR_FAULTS path for generic STATUS_WORD alarms, including devices whose status accessor uses STATUS_BYTE. Keep individual byte writes for detailed status registers on PMBus 1.2 and newer devices. As with the existing older-device fallback, CLEAR_FAULTS can clear other latched status; an active condition can reassert its status. Fixes: 35f165f08950 ("hwmon: (pmbus) Clear pmbus fault/warning bits after read") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Vishnu Razdan Link: https://patch.msgid.link/20260824-vrazdan-pmbus-status-word-b4-v1-1-2606ecd0c029@openai.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit cbe296250d57c4572050fcd085a569ad7acfddd4 Author: Cong Nguyen Date: Fri Aug 28 17:54:13 2026 +0700 hwmon: (applesmc) fix key backlight workqueue leak on register failure commit 5a0aacaa2d593d7582ecfe289529b937b6dc5d3c upstream. applesmc_create_key_backlight() allocates applesmc_led_wq before calling led_classdev_register(). When register fails, the error is returned to applesmc_init(), which jumps to out_light_sysfs and skips applesmc_release_key_backlight(), leaking the workqueue. Destroy the workqueue on the register failure path. The bug was introduced when the inline init block was refactored into a helper that returns errors directly, dropping the old out_light_wq unwind label. Fixes: 0b0b5dff8967 ("hwmon: (applesmc) Simplify feature sysfs handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260828105413.2401385-1-congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 538f00558db9a66aeff20c36f43692c178a0e0eb Author: Harald Freudenberger Date: Mon Aug 31 10:37:34 2026 +0200 s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm commit 8b7c3b6914f19caf648d05726a86af6326d3c2c6 upstream. In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out. Fixes: d07f951903fa ("crypto: s390/aes - Fix buffer overread in CTR mode") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit c66df28df64c844776d571757545304c826df060 Author: Nagamani PV Date: Tue Sep 1 17:53:44 2026 +0200 s390/qeth: allow bridgeport queries despite OS_MISMATCH commit 74f27fc8642b7e8d139796f8c18ee46df393c2b2 upstream. When HiperSockets interfaces on the same VCHID span different OS families, reads of the sysfs attributes bridge_role and bridge_state fail with -EPERM if bridge port ownership belongs to another OS family. As a result, userspace tools such as 'lszdev -ii' cannot retrieve bridge_role and bridge_state, even though firmware returns valid bridge port data for QUERY_BRIDGE_PORTS requests. The firmware reports IPA_RC_SBP_IQD_OS_MISMATCH (0x0010) to indicate that bridge port ownership belongs to a different OS family. For QUERY_BRIDGE_PORTS operations, firmware still returns valid bridge port data (role=none, state=inactive) together with a primary return code of 0x0000 (success). Allow QUERY_BRIDGE_PORTS requests to return the bridge port data provided by the firmware despite OS_MISMATCH. To make the OS family mismatch visible to userspace, represent the firmware-reported role "none" as "none (OS family mismatch)" while preserving the reported bridge_state. The behavior for non-QUERY bridge port commands is unchanged; SET operations continue to return -EPERM when another OS family owns the bridge port. This restores readability of bridge_role and bridge_state. Fixes: 1b05cf6285c1 ("qeth: Include error message for "OS Mismatch"") Cc: stable@vger.kernel.org Suggested-by: Halil Pasic Reviewed-by: Alexandra Winter Signed-off-by: Nagamani PV Link: https://patch.msgid.link/20260901155344.3561483-1-nagamani@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6c88aa7fcdf87cc455c46e38f3bdc9466fb99fe4 Author: leixiang Date: Thu Jul 9 13:57:52 2026 +0800 KVM: PPC: Book3S HV: Set irqfd->producer only on success commit 1144454ea22290d7c6998a2af6239e5995476afc upstream. Set irqfd->producer only after kvmppc_set_passthru_irq() succeeds to avoid leaving a dangling pointer on failure. The bypass manager does not register a failed producer, so the pointer is never cleared. Fixes: c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: leixiang Reviewed-by: Amit Machhiwal Reviewed-by: Vaibhav Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260709055755.31297-1-leixiang@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 5677e81ffdbfc1c03dcb427fb8b1c38289bed76d Author: Kyle Zeng Date: Mon Aug 10 15:10:34 2026 -0700 ipvs: reject invalid states in connection template sync records commit 74cb39735b6cd0aff4b5584158f09376fd97aadf upstream. IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records. Fixes: 275411430f89 ("ipvs: add assured state for conn templates") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 999bc00588cb305ab25065e8a8ac31da7465301c Author: Zihan Xi Date: Tue Sep 1 10:59:04 2026 +0000 ipv4: fib: bound automatic table ID allocation commit efdfb1e27a3328085b79540dfe781d537b576ea1 upstream. fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0. Fixes: b801f54917b7 ("[NET]: Increate RT_TABLE_MAX to 2^32") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Ido Schimmel Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Reviewed-by: Petr Vorel Link: https://patch.msgid.link/6f2f2a7a136aee005512a2e1ac8ede62ac8c7bb6.1788258884.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a1760f21c32adce41af5ed5687200865d8feaaeb Author: Zhiling Zou Date: Sat Aug 29 18:07:23 2026 +0800 ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink commit bf79662bc85e820ac3b846e2f347da29fbf6ac95 upstream. TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type. Fixes: 51e0e5d8124e ("ieee802154: 6lowpan: remove multiple lowpan per wpan support") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://lore.kernel.org/0b715da69bd15a86ddc47dad5cf12da648211050.1787997209.git.zhilinz@nebusec.ai Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit bf49eac7ed11aabd0b9b790c062742a8e4be97c6 Author: Weiming Shi Date: Thu Sep 10 03:10:23 2026 +0800 fbdev: vfb: defer cleanup until the last reference commit a0a34a40ed299c9c7cff6af163a5b883ee9d6d73 upstream. FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released. Fixes: 5e266e2e0e19 ("vfb: fix memory leaks in removal path") Reported-by: co+c25629c98ba36ebe@bugs.sh Cc: stable@kernel.org Closes: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Assisted-by: Codex:gpt-5 Signed-off-by: Weiming Shi Link: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit bbcbff6b9bb38a264a964b384dbb6a4b2a245851 Author: Ilya Maximets Date: Tue Aug 25 17:27:24 2026 +0200 netfilter: report NLM_F_DUMP_FILTERED when all is filtered out commit 7a099b347fef536a84068076e2d384f044e5cfc5 upstream. NLM_F_DUMP_FILTERED is only set on data elements in the conntrack dump. But when everything is filtered out it is confusing for the user space, since the flag is not reported anymore and it looks like the table was empty, which may or may not be the case. 'answer_flags' were introduced precisely for this use case, and the conntrack dump should set the flag in there in case the filtering was applied. This is important, for example, to be able to tell if the filters are supported or not by the kernel without modifying the kernel state. With the proper reporting of NLM_F_DUMP_FILTERED on NLMSG_DONE, an application in user space can just try and dump with an arbitrary filter without worrying that there could be no matching entry. The reported flag will signal that the filtering was applied and therefore supported. Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 4c98b492e9ed63f9ca3e23566d9a6a4f235944f4 Author: Norbert Szetei Date: Sun Sep 6 10:21:09 2026 +0200 net: openvswitch: fix use-after-free of the flow table mask array commit ba4ba11ed6eb8972c69070417fc27b48deb002e8 upstream. tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: old = ovsl_dereference(tbl->mask_array); if (old) { ... call_rcu(&old->rcu, mask_array_rcu_cb); } rcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap. Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Acked-by: Eelco Chaudron echaudro@redhat.com Link: https://patch.msgid.link/DE115F9C-2545-423E-A702-986FC952FD62@doyensec.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 55ed97db27bffe29c21fdefd5d25601322c36ff8 Author: Fourie Zhang Date: Wed Sep 2 17:27:12 2026 +0800 net: mpls: clear inner_protocol when the last label is popped commit 78a86d75a70e1e227711c72865c59b1422d0a5ae upstream. skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: skb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: if (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: unsigned int hlen = skb_network_offset(skb); memcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 ("ipv6: sr: restore network header before routing and forwarding"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does. Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO") Cc: stable@vger.kernel.org Signed-off-by: Fourie Zhang Acked-by: Jiri Benc Link: https://patch.msgid.link/20260902092719.2874481-1-fouriezhang@tencent.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bb99bcd8b18c04f4bd4789074027212a02b72d23 Author: Johan Hovold Date: Mon Sep 7 08:52:35 2026 +0200 net: hso: fix TIOCMIWAIT race commit 00f9fbc12320253bfc576fb7539d860029c82d0f upstream. The task state must be updated before checking the wakeup condition to avoid missing a racing modem status update. Fixes: 542f54823614 ("tty: Modem functions for the HSO driver") Cc: stable@vger.kernel.org # 2.6.29 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907065235.100848-1-johan@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit d60532306397233fb860860e9694f4e35abc0e80 Author: Thorsten Blum Date: Sun Aug 23 22:50:28 2026 +0200 drm/i915: Fix memory leak in query_perf_config_list() commit cbd3dafc2003db679ccd2f6c6a2551db79657049 upstream. When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. Fixes: 4f6ccc74a85c ("drm/i915: add support for perf configuration queries") Signed-off-by: Thorsten Blum Cc: # v5.5+ Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260823205028.178597-2-thorsten.blum@linux.dev (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 955973fff4a36d39a848b00cac1706863f568fe1 Author: Jann Horn Date: Mon Sep 7 23:26:32 2026 +0200 exec: do_close_on_exec() before taking exec_update_lock commit e780259b54e618ceb4763fbc21314acf3565e813 upstream. do_close_on_exec() currently happens while holding the exec_update_lock, which is used in a lot of places that access process state to synchronize access checks. I recently added another such use of exec_update_lock, causing a regression. do_close_on_exec() can block waiting for a reply from a filesystem. That means a hung filesystem can block codepaths that use exec_update_lock; and it also means that a FUSE filesystem which attempts to inspect the calling process can deadlock. To avoid such problems, move do_close_on_exec() before the exec_update_lock is taken, but after the FD table has been copied if necessary. I have looked through all the calls between the old and new position of the do_close_on_exec() call; there seems to be no file descriptor table access in between. Reported-by: Benjamin Peterson Closes: https://lore.kernel.org/r/f5e8166a-88be-46c5-8939-1e5227ffe4c2@app.fastmail.com Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260907-cloexec-before-exec-update-lock-v1-1-8018c201a7df@google.com Tested-by: Benjamin Peterson Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c9d8435814f2ac533c40fe3f35d94235bc3a9443 Author: Runyu Xiao Date: Wed Sep 2 12:19:15 2026 +0800 cpufreq: initialize policy rwsem before sysfs publication commit 3e5d1bf4bd687beb2cb4e32a07af695455925588 upstream. cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore. Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy") Cc: All Applicable Link: https://lore.kernel.org/all/20260830155301.2713780-1-runyu.xiao@seu.edu.cn/ Reviewed-by: Zhongqiu Han Signed-off-by: Runyu Xiao Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260902041915.3453421-1-runyu.xiao@seu.edu.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e13370c5b549712f49f80234df249303381c53b4 Author: Zhongqiu Han Date: Tue Sep 1 22:36:35 2026 +0800 cpufreq: zero-initialize policy cpumask before sysfs publication commit 54d37bcf2f497140b9207968557ddb484058e749 upstream. cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus. Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy") Cc: All applicable Signed-off-by: Zhongqiu Han Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260901143635.4106960-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9128265f0fc8031a71775d70786052e5631aac54 Author: Runyu Xiao Date: Sun Aug 30 22:20:26 2026 +0800 ASoC: sti: initialize IRQ lock before requesting IRQ commit 04405aeef4f8d7bcac6dcb1947acafdb4420c2c3 upstream. uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state. Fixes: d05d862ead8e ("ASoC: STI: Fix null ptr deference in IRQ handler") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830142026.2666914-1-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2fada8276117215407afd1f59de5d2fe22aff01f Author: Tianchu Chen Date: Mon Aug 31 15:13:36 2026 +0000 ASoC: sprd: validate compress buffer sizes against fixed allocations commit 7a4ce92d150b9e7ecf1a710a34d8cdeb590d3751 upstream. sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: cce1396936ef ("ASoC: sprd: Add Spreadtrum audio compress offload support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/4386bc53631b052c1866a91061715b009d98b04f@linux.dev Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 608b7751926ec08fae6a1ac4e7308195da68c362 Author: Donggeun Yoo Date: Sun Sep 6 22:33:52 2026 +0900 tracing: Free histogram the var ref when its initialization fails commit 516001d53e6b2ea95a251ee2ef54a1a689a3fd58 upstream. create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906133352.3815019-1-donggeunyoo.kernel@gmail.com Fixes: 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3978b9719aabc6c6d3cc5d5e04da63a565bcad57 Author: Ido Schimmel Date: Wed Sep 2 22:01:12 2026 +0300 tunnels: Drop stale dst when building an ICMP error for PMTUD commit b58d749633203d92c265317b45fccee555090352 upstream. Bridged UDP tunnels such as VXLAN and GENEVE build an ICMP error packet around an overlay packet if the packet is going to exceed the underlay path MTU. The ICMP error packet is then injected back into the Rx path with the source and destination addresses swapped, so that it will be delivered to the overlay source. If the overlay packet was routed to the UDP tunnel or locally generated, then it is already carrying a valid dst entry and this entry is not dropped when transforming the packet to an ICMP error packet. This causes the IP layer to reuse the dst entry, leading to the ICMP error packet being dropped or routed out of the UDP tunnel interface in case of forwarding. Prior to the blamed commit this could not happen, as skb_tunnel_check_pmtu() did not build ICMP errors for PACKET_HOST packets. Such packets were instead encapsulated and, unless the DF bit was set in the outer header, fragmented by the underlay. Fix this by making sure that the ICMP error packet does not have a valid dst entry, thereby forcing the IP layer to perform a route lookup. Adjust the bridged PMTU exception selftests accordingly. When the local sender in ns_a pings the overlay destination with a deadline (-w), ping exits on the first socket error before any reply is received and returns a non-zero exit code. The test therefore only passed because the ICMP error was never delivered. Use a packet count (-c) like the ns_c line above it, so that the ICMP error counts against the packet budget and the exit code depends on whether echo replies were received. This passes with and without the fix. Fixes: 8930424777e4 ("tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu().") Cc: stable@vger.kernel.org Reported-by: Laika Price Closes: https://lore.kernel.org/netdev/20260614-master-v3-1-9f5060ba1ed1@gmail.com/ Reported-by: Yaroslav Dudkov Closes: https://lore.kernel.org/netdev/20260901081825.287173-1-aroslavdudkov622@gmail.com/ Reported-by: Charles Bordet Closes: https://lore.kernel.org/netdev/aHVhQLPJIhq-SYPM@eldamar.lan/ Signed-off-by: Ido Schimmel Tested-by: Yaroslav Dudkov Reviewed-by: David Ahern Reviewed-by: Stefano Brivio Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/20260902190112.4126199-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 88cccb6beba136b73f0caf80e59457e1b3c0ca1e Author: Ali Ahmet Memis Date: Sat Aug 1 10:12:58 2026 +0300 ufs: validate cylinder group metadata before caching it commit c9d263be26806d388129fab8c6904bed197fc6af upstream. ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: ucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); ucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); ucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); ucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801071306.59484-3-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e58db6c2dce6e453dca26c3a4953002425201880 Author: Ali Ahmet Memis Date: Sat Aug 1 10:12:57 2026 +0300 ufs: create the root dentry after loading cylinder metadata commit 55a4c98abb9694b067c6a031d11501f06b6b523c upstream. ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: sb->s_root = d_make_root(inode); ... if (!sb_rdonly(sb)) if (!ufs_read_cylinder_structures(sb)) goto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801071306.59484-2-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2a1dd175e53bb90eb8d15b34c47007514556a8ee Author: James Hilliard Date: Thu Aug 27 22:42:31 2026 -0600 watchdog: sunxi_wdt: preserve boot-enabled watchdog commit aab55360fa11a2c054798a484ac67ad606f563e4 upstream. sunxi_wdt_probe() unconditionally stops the watchdog even when firmware left it running. This opens an unprotected interval during boot and prevents CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED from taking over the active watchdog. Detect an enabled watchdog and decode its programmed interval. Preserve representable timeouts, and round the 0.5-second interval up to the minimum representable one-second timeout. Use the configured timeout for reserved interval encodings. Set the Linux reset mode and ping the watchdog without clearing its enable bit, then mark it hardware-running before registration so the watchdog core services it until userspace takes control. Leave disabled watchdogs untouched. Fixes: d00680ed0026 ("watchdog: sunxi: New watchdog driver for Allwinner A10/A13") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Link: https://patch.msgid.link/20260827-submit-sunxi-wdt-boot-enabled-v1-v2-1-610d37dccc97@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9a90afd2f56f1061db0fd3a7cc28c287a5cca70e Author: Harry Wentland Date: Tue Jun 16 13:39:21 2026 -0400 dm/amdgpu: fix malformed link_settings debugfs output commit 622b4e8505aa7453a53d17fa3a288871f270fc8b upstream. [Why] dp_link_settings_read() passed strlen() of each format string as the size argument to snprintf() and then advanced rd_buf_ptr by that same fixed amount. The format-string length has no relation to the formatted output length, so snprintf() truncated each field at a NUL it wrote inside the buffer while the pointer was advanced past it. The result is a buffer peppered with embedded NUL bytes and fields that are silently cut short, so the data read back from the debugfs node does not reflect the actual link settings. [How] Use scnprintf() with the real remaining buffer size (rd_buf_size - (rd_buf_ptr - rd_buf)) and advance rd_buf_ptr by its return value, which is the number of characters actually written. This both bounds each write to the space left in rd_buf and keeps the output a single, properly terminated string. The now-unused str_len local is removed. Fixes: 41db5f1931ec ("drm/amd/display: set-read link rate and lane count through debugfs") Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Harry Wentland Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 43b9f0f18693c7f7b75613f3aeae25fa2b4e2f76) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 54b06575fc51974412b7eae6f1d7996f7dbae0db Author: Roman Prucha Date: Thu Sep 3 23:14:44 2026 +0200 ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough commit b26a7a80e6bbf8dd17dacb127d12435d79375cf2 upstream. dao_rsc_init() encodes the DAIO configuration as conf = (desc->msr & 0x7) | (desc->passthru << 3); S/PDIF passthrough uses msr=1 and passthru=1, resulting in conf=9. daio_mgr_dao_init() masks conf with 0xf, but handles only values 1, 2, 4 and 8 when programming ATXCTL_NUC. As a result, conf=9 falls through to the default case and leaves NUC at its previous setting. On a Creative X-Fi Titanium HD SB1270 (CA20K2), this breaks AC3 IEC61937 passthrough when snd_ctxfi runs with reference_rate=48000,multiple=2. The receiver detects a non-audio stream but cannot decode the AC3 payload. With the unmodified driver, multiple=1 makes the same stream work. Handle conf=9 through the same NUC=0 path as conf=1. The change was runtime tested on the SB1270 with multiple=2 using IEC958 stereo PCM, pre-encoded AC3 IEC61937 passthrough and ALSA A52 live 5.1 encoding. Fixes: 26a9630c72eb ("ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Roman Prucha Link: https://patch.msgid.link/20260903-ctxfi-spdif-conf9-fix-v1-1-5e4e3e1f801c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9a3f73d62c86271614eda4c43315230896a37018 Author: Zihan Xi Date: Tue Sep 8 07:42:56 2026 +0000 ipv6: fix fib6 walker UAF on seq stop commit 19b4ed644d68098cc62ab612727f40d30f43476c upstream. ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race. Fixes: 8d2ca1d7b5c3 ("ipv6: avoid high order memory allocations for /proc/net/ipv6_route") Cc: stable@vger.kernel.org Reported-by: Vega Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/89699735763f6c297584d7c2ff106239cc1e8ce0.1788837093.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3833dfae0680b6b16e2469fbc90aa48376311cd8 Author: Shivaprasad G Bhat Date: Tue Jul 14 17:16:23 2026 +0000 powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver commit c5e68706527968282e49de205cc2b935823cb88a upstream. The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined). Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Cc: stable Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Shivaprasad G Bhat Reviewed-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178404937381.913.2759874335293830160.stgit@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit c2ef3f134b069c54b9cc95cce1a16c38c4939336 Author: Eric Dumazet Date: Tue Sep 15 16:27:02 2026 +0200 macvlan: inherit needed_headroom and needed_tailroom from lowerdev [ Upstream commit cef51860becd9700217c81732ca1eb1ea6ed6fe1 ] macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#m16adf0ff972cbfd8066c3a8e656e75eaeb12d021 Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260806141938.287660-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit b070c8b4b237d55bdac13da3c5a994491177b312 Author: Maurizio Lombardi Date: Fri Jul 17 16:38:28 2026 +0200 scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands [ Upstream commit d5869dae5080e976d4b03cc33eb7ceb527f242bf ] When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock. Signed-off-by: Maurizio Lombardi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260717143828.76291-2-mlombard@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 102c0a62a268420fe2f538fec9025fb04a46ac2a Author: Dmitry Bogdanov Date: Sat Mar 18 20:56:20 2023 -0500 scsi: target: iscsi: Handle abort for WRITE_PENDING cmds [ Upstream commit ea87981a0ee8fb8ced1c87d004a541b60623ff97 ] Sometimes an initiator does not send data for a WRITE command and tries to abort it. The abort hangs waiting for frontend driver completion. iSCSI driver waits for data and that timeout eventually initiates connection reinstatment. The connection closing releases the commands in the connection, but those aborted commands still did not handle the abort and did not decrease a command ref counter. Because of that the connection reinstatement hangs indefinitely and prevents re-login for that initiator. Add handling in TCM of the abort for the WRITE_PENDING commands at connection closing moment to make it possible to release them. Signed-off-by: Dmitry Bogdanov [mnc: Rebase and expand comment] Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230319015620.96006-10-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 983a05793585f810a5efec9f54c564835acd5b42 Author: Sasha Levin Date: Tue Sep 15 18:51:20 2026 -0400 Revert "bluetooth/l2cap: sync sock recv cb and release" This reverts commit 2243127db6ba20cbef90c6349a2b1000af401d2e. Signed-off-by: Sasha Levin commit 92b7c6e3a1546c6db868b07e93fa6fb950d1d3a0 Author: WenTao Liang Date: Tue Sep 15 10:46:09 2026 +0300 drm/amd/display: set new_stream to NULL after release commit 9fa26b9eed6195bf840f39ac183b9a6237548755 upstream. In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required") Signed-off-by: WenTao Liang Reviewed-by: George Zhang Signed-off-by: Alex Deucher Signed-off-by: Roman Demidov Signed-off-by: Sasha Levin commit eb9c5f6747fe98b83c78cb5476a914e91d50e8e8 Author: Stian Halseth Date: Tue Sep 1 19:39:45 2026 +0200 sunvdc: unmap LDC cookies when the descriptor send fails [ Upstream commit 0c6da21fa35e03fc74f09895433ccd6d4a9c3530 ] __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched. Fixes: a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") Reported-by: John Paul Adrian Glaubitz Link: https://github.com/sparclinux/issues/issues/2 Signed-off-by: Stian Halseth Link: https://patch.msgid.link/20260901173947.3292110-2-stian@itx.no Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7d7705ce73eac1de1146706d887bc969a48ebb6d Author: Greg Marsden Date: Sat Sep 5 10:00:41 2026 -0700 net/rds: fix tcp stream corruption with large pages [ Upstream commit 2ac09b5353fe6858411fdc8c6efa60d832e20f13 ] rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes. Fixes: 7875e18e0996 ("RDS: Message parsing") Signed-off-by: Greg Marsden Reviewed-by: Allison Henderson Link: https://patch.msgid.link/apxJjxvStibPI0AS@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42b9536c2a5fa48ab3b56000021511648c9b8001 Author: Linus Walleij Date: Mon Aug 29 15:20:01 2022 +0200 net/rds: Pass a pointer to virt_to_page() [ Upstream commit a60511cf15204e41f4edbcdc4ee80208d528917c ] Functions that work on a pointer to virtual memory such as virt_to_pfn() and users of that function such as virt_to_page() are supposed to pass a pointer to virtual memory, ideally a (void *) or other pointer. However since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). If we instead implement a proper virt_to_pfn(void *addr) function the following happens (occurred on arch/arm): net/rds/message.c:357:56: warning: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion] Fix this with an explicit cast. Cc: Santosh Shilimkar Cc: rds-devel@oss.oracle.com Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220829132001.114858-1-linus.walleij@linaro.org Signed-off-by: Jakub Kicinski Stable-dep-of: 2ac09b5353fe ("net/rds: fix tcp stream corruption with large pages") Signed-off-by: Sasha Levin commit 7cc974799fde846eda2d8f00ad4f8e1810eb0499 Author: Aamir Ahmed Date: Mon Sep 7 02:42:34 2026 +0000 net: hinic: fix mailbox segment buffer overflow [ Upstream commit 5d4d985957434867bbe85e4fa5e638f3e48ad522 ] check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver. Fixes: a425b6e1c69b ("hinic: add mailbox function support") Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB0001AE870B09020B46B5D7DBC8B22@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 13e9fc9b1a56723690fae05cc33db8b77cb26a44 Author: Li Youhong Date: Fri Sep 4 16:07:58 2026 +0800 net: sun4i-emac: fix missing of_node_put() for phy_node [ Upstream commit af406abfecad2f48d8f1fc646d3994f0982bac62 ] of_parse_phandle() returns a node pointer with an elevated refcount. Add the missing of_node_put() on the probe error path after register_netdev() fails and in emac_remove(). Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: Li Youhong Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904080758.2432748-1-dayou5941@163.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 240251a4ca7cda213103694b6e21c4a5745e5d8b Author: Kuniyuki Iwashima Date: Tue Sep 8 20:55:25 2026 +0000 net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). [ Upstream commit dff39930ad5e53d202bfdfb14687d1d2fd753b4d ] If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 ("net: sched: introduce chain object to uapi") but was not used initially. Since commit 9f407f1768d3 ("net: sched: introduce chain templates"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 2ed9db3074fc ("net: sched: cls_api: fix dead code in switch") Reported-by: Taras Madan Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jamal Hadi Salim Tested-by: hybris@mojatatu.ai Link: https://patch.msgid.link/20260908205537.863484-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9e7741b41a25b9d49df4d262fa314342e6f95c50 Author: Victor Nogueira Date: Mon Sep 7 16:21:30 2026 -0300 net/sched: cls_route: free emptied bucket on filter move [ Upstream commit 1853f30cf5c84971f99788a76207c6f745380896 ] route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 ' Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-2-victor@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0b4aa85cd425f0485f3cf63b444f6e2292356476 Author: Thibault Ferrante Date: Mon Sep 7 23:54:20 2026 +0200 selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value [ Upstream commit ed28b16eab705071d28edaace47189c2eb3aa108 ] tcheck() is used to check the current transaction state (active, suspended, doomed) via the "tcheck" instruction, which writes its result into CR field 0. The inline asm declared a GPR output operand for this result but never actually moved the CR into it. Every caller (tcheck_doomed(), tcheck_active(), tcheck_suspended(), tcheck_transactional()) has effectively been testing bits of an unrelated, arbitrary register value since this helper was introduced. The "& 4" mask discards the TDOOMED and TS_lsb (suspended) bits before they ever reach the callers, so tcheck_doomed() and tcheck_suspended() can never return true, and tcheck_transactional() degrades to being equivalent to tcheck_active(). Fix tcheck() to actually move CR into the output register with mfcr, and widen the mask from "& 4" to "& 0xf" so the full CR0 nibble (TDOOMED | TS_msb | TS_lsb | reserved) is preserved for the callers. This bug has been present since tcheck() was introduced. Link: https://bugs.launchpad.net/bugs/2107442 Fixes: 8e03bd4e70b6 ("selftests/powerpc: Add TM tcheck helpers in C") Signed-off-by: Thibault Ferrante Reported-by: Venkat Rao Bagalkote Tested-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/364996ce-aba2-4213-8d20-7dd481b43fe6@linux.ibm.com/ Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260907215420.1258678-1-thibault.ferrante@canonical.com Signed-off-by: Sasha Levin commit 6955cbaffd439c270574f00feb8ae4cdf8b18ca8 Author: Pengpeng Hou Date: Sun Aug 30 20:50:44 2026 +0800 hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors [ Upstream commit 09a9e1746a87845d7d8e2b4e23bb613306effdff ] aspeed_pwm_tacho_probe() installs its reset cleanup action and configures the controller after an unchecked reset deassertion. Stop probing when the reset controller rejects the transition, before the hwmon device becomes visible. Fixes: 18c514cc0e02 ("hwmon: (aspeed-pwm-tacho) Deassert reset in probe") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830125044.97718-1-pengpeng@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit fa53d89479cbb5f5dcdac31a94effcf5a8f821ea Author: Cong Nguyen Date: Tue Sep 1 22:54:04 2026 +0700 hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown() [ Upstream commit bb2424c3502cc72292eedade46960c331d5f28fb ] set_fan_speed() writes the control GPIOs one bit at a time. Every other caller locks around it; gpio_fan_shutdown() doesn't. If it races a locked caller, the GPIO writes can interleave and leave the fan at a speed neither caller asked for. Fixes: b95579cd8795 ("hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans") Reported-by: Sashiko AI review Link: https://lore.kernel.org/r/20260830152150.27F5F1F000E9@smtp.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260901155404.1532092-1-congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit de1e03d94e8a11d001f801b99baeeb2dc8816dd6 Author: Linus Walleij Date: Thu Sep 3 23:45:33 2026 +0200 net: ethernet: cortina: Count RX descriptors for freeq refill [ Upstream commit e89e88ad41d9f31c829c2af39c48313e8e48d5b0 ] The software free queue provides one buffer fragment for every descriptor moved to an RX queue. The refill heuristic instead advances by NAPI work, which counts frames. A fragmented or discarded frame can consume several queue entries while adding only one to the refill count. Count the RX descriptors as they are consumed and report that separately from NAPI work. Use the descriptor count to drive free queue refills. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-5-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 08e123235c572c4fd404db1c3206736af830bc7d Author: Linus Walleij Date: Thu Sep 3 23:45:32 2026 +0200 net: ethernet: cortina: Count RX drops once per frame [ Upstream commit 6520198c430c81bcc367f0dd5e32f2fb740b9d51 ] The absence of a partial skb means either that the driver is not assembling a frame or that the current frame was already dropped. Consequently, repeated descriptor errors can increment rx_dropped more than once, while an orphaned descriptor chain can reach EOF without being counted at all. Track the dropping state across NAPI polls. Clear it at frame boundaries and route mapping failures and orphaned continuations through the common drop path so each discarded frame is counted exactly once. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Reported-by: Joe Damato Closes: https://lore.kernel.org/netdev/apdK5aMmvYssz35F@devvm20253.cco0.facebook.com/ Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-4-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 179584fcd203b515470d437b6bfa34e6330c4a22 Author: Linus Walleij Date: Sat May 9 00:13:36 2026 +0200 net: ethernet: cortina: No mapping is a dropped rx [ Upstream commit 2cb156213093a62b80cf40b1ec71738e93491971 ] Increase stats.rx_dropped++ even if this is the first fragment (skb == NULL) so we are doing proper accounting. Fixes: b266bacba796 ("net: ethernet: cortina: Drop half-assembled SKB") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-1-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 6520198c430c ("net: ethernet: cortina: Count RX drops once per frame") Signed-off-by: Sasha Levin commit 620b7184808b25cf58268856f892b9ba83c181fd Author: Linus Walleij Date: Thu Sep 3 23:45:31 2026 +0200 net: ethernet: cortina: Count dropped frames as NAPI work [ Upstream commit b856c552f556bc0341c1dbe0bf88e630fd1dc4b7 ] The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-3-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 641ef299a540b2efdc5d2e7e164b34e602219dcb Author: Linus Walleij Date: Thu Sep 3 23:45:30 2026 +0200 net: ethernet: cortina: Finish RX updates before NAPI completion [ Upstream commit baa26841cb9a2cdc7e0e99d6854a4e3359bf7393 ] napi_complete_done() releases ownership of the NAPI instance, but the Gemini poll keeps the RX statistics writer section open and updates the free queue after calling it. A new poll can therefore start while the old writer is still active. Finish the statistics and free queue updates before releasing ownership. Only re-enable RX interrupts when napi_complete_done() reports successful completion. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Suggested-by: Joe Damato Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-2-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d3deb54d9507c2d7f05efd896142095eef5b7d85 Author: Linus Walleij Date: Thu Sep 3 23:45:29 2026 +0200 net: ethernet: cortina: Fix budget accounting [ Upstream commit a0de06d0da78a3db53de65dfd7452cc6d111f703 ] The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://lore.kernel.org/r/20260509-gemini-ethernet-fixes-v1-4-6c5d20ddc35b@kernel.org Link: https://lore.kernel.org/r/20260512131456.189452-1-pabeni@redhat.com Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-1-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ab05a6abe6c1f24d378b4bba65d8c70fac8fd3d8 Author: Andrew Stellman Date: Fri Sep 4 10:13:18 2026 -0400 virtio-pci: return IRQ_HANDLED after non-zero ISR [ Upstream commit 93fa09455fb1a9624b73d42ac1f83771f4818e80 ] vp_interrupt() reads the ISR before dispatching config-change and vring handling. Reading the ISR also clears it, so once the read returns non-zero the interrupt was from this device and has already been consumed. Currently vp_interrupt() returns the result of vp_vring_interrupt(). For a config-change interrupt with no vring work, that can return IRQ_NONE even though the ISR was non-zero and the interrupt was handled. Call vp_vring_interrupt() for any queue work, but once the ISR is non-zero return IRQ_HANDLED. Tested with QEMU virtio-blk-pci forced to INTx using vectors=0 and pci=nomsi. On an idle device, 200 config-change interrupts were generated using QMP block_resize. Before this change, irq_handler_exit reported ret=unhandled and /proc/irq/11/spurious increased from 0 to 200 unhandled interrupts. After this change, irq_handler_exit reported ret=handled and the unhandled count remained at 0. The issue was found during an LLM-assisted Quality Playbook review. Fixes: 77cf524654a8 ("virtio_pci: split up vp_interrupt") Suggested-by: Michael S. Tsirkin Assisted-by: LLM Signed-off-by: Andrew Stellman Message-ID: <20260904141318.30278-1-astellman@stellman-greene.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit e260dc9fbfdae0978e7a8698f977fbb463a657be Author: Yu Zhang Date: Fri Aug 7 20:00:24 2026 +1000 vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx [ Upstream commit e74a9fa50749b9940b4fb13199652325e08d3c4a ] vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: ctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); swap(ctx, v->config_ctx); if (!IS_ERR_OR_NULL(ctx)) eventfd_ctx_put(ctx); if (IS_ERR(v->config_ctx)) { long ret = PTR_ERR(v->config_ctx); v->config_ctx = NULL; return ret; } Commit 0bde59c1723a ("vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails") added that clearing, and spelled out the invariant the rest of the file relies on: "we consider 'v->config_ctx' valid if it is not NULL". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang Signed-off-by: Michael S. Tsirkin Message-ID: <20260807100025.19750-2-yuz08559@gmail.com> Signed-off-by: Sasha Levin commit b1f39c2a676698cc64c8e105e08b25111a112ec6 Author: Jia Jia Date: Wed Aug 19 10:12:30 2026 +0800 virtio_console: do not free control-out buffers on remove [ Upstream commit 894f98e73983f37354214a89a3a7fd35bf9e3072 ] __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): free_buf remove_vqs virtcons_remove unbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it. Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260819021230.292696-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit 4ac8671f16bc54506eec946a081f401009aa7fe2 Author: Xianting Tian Date: Fri Jun 9 21:18:16 2023 +0800 virtio-console: call scheduler when we free unused buffs [ Upstream commit 56b5e65efe0001fb5f95e412ee4167363debfc46 ] For virtio-net we were getting CPU stall warnings, and fixed it by calling the scheduler: see f8bb51043945 ("virtio_net: suppress cpu stall when free_unused_bufs"). This driver is similar so theoretically the same logic applies. Signed-off-by: Xianting Tian Message-Id: <20230609131817.712867-3-xianting.tian@linux.alibaba.com> Signed-off-by: Michael S. Tsirkin Stable-dep-of: 894f98e73983 ("virtio_console: do not free control-out buffers on remove") Signed-off-by: Sasha Levin commit b45afb076f89b4acc22ba7bb157d1015b46057cb Author: hpp.iscas Date: Sat Sep 5 21:32:10 2026 +0800 ASoC: mt6351: Publish the OF module alias [ Upstream commit 9c3882ec10399c14c59b7e4599d33c4395367c37 ] The MT6351 codec platform driver uses mt6351_of_match to bind devices with compatible mediatek,mt6351-sound. The codec can be a separate module, but the OF table is not exported to module alias metadata. Publish the existing table without changing codec matching, register access or the machine-driver configuration. Fixes: a74d51ba0e17 ("ASoC: add mt6351 codec driver") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133210.63803-1-hppiscas@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9d58e4c72e8584dcf9af724b1005f645411eccdc Author: Florian Westphal Date: Tue Aug 25 15:11:24 2026 +0200 netfilter: ip6_tables: set F_PROTO when proto value is nonzero [ Upstream commit da4afc5a956d407443988e97a4d4ca14c2e999c7 ] The ip6tables traverser doesn't search the extension header chain unless userspace did set the IP6T_F_PROTO flag. This also means that userspace that sets the e->ipv6.proto flag can bypass the protocol check for the rule by not setting this flag. That in turn means that all ip6_tables modules and targets that want to reject rules without '-p' flag MUST also check for that flag. Not all do, likely because they got copied from iptables which lacks this flag (no extension headers). Instead of fixing up all the relevant targets, emulate ip6tables behaviour in the kernel (like nft_compat.c) and set the flag if the protocol is set. Reported-by: Zhiling Zou Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c5c89beaa628d6ac527c6eb2e01b2b52eb417f59 Author: Florian Westphal Date: Tue Aug 25 03:36:03 2026 +0200 netfilter: nfnetlink_log: cope with concurrent instance destruction [ Upstream commit 387d744fa7e499d2c3748a4e60e02ebb24e7fb16 ] Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0 Fixes: 0597f2680d66 ("[NETFILTER]: Add new "nfnetlink_log" userspace packet logging facility") Reported-by: Eulgyu Kim Reported-by: Jaeyoung Chung Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f259a74147e324cd01511d40206a47d072361b75 Author: hpp.iscas Date: Sat Sep 5 21:31:33 2026 +0800 ASoC: Intel: SST: Publish the PCI module aliases [ Upstream commit d112159df5c6cc5ee6ab91cc32bf6ed29939df38 ] The legacy SST PCI driver matches Intel Tangier devices using intel_sst_ids, but its only explicit module alias is "sst". That alias does not match PCI modalias events when this driver is built as a module. Publish its PCI table. The independently configurable SOF driver does not provide aliases for the legacy SST module. Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133133.63661-1-hppiscas@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 720cb5cc675c22d1863b3672754169a2afe2fcbd Author: hpp.iscas Date: Sat Sep 5 21:31:03 2026 +0800 ASoC: bcm: bcm63xx: Publish the OF module aliases [ Upstream commit 32689f0fc54fd801f1cd11637666e534984cb04a ] The BCM63xx I2S platform driver matches brcm,bcm63xx-i2s using snd_soc_bcm_audio_match. With SND_BCM63XX_I2S_WHISTLER=m, the platform bus emits an OF modalias but snd-soc-63xx does not publish that table. Export the existing OF IDs for module autoloading. The PCM companion and the probe path remain unchanged. Fixes: 88eb404ccc3e ("ASoC: brcm: Add DSL/PON SoC audio driver") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133103.63432-1-hppiscas@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a3bbd2845bc7188ae18548a591da1067af997e80 Author: Edward Adam Davis Date: Thu Sep 3 21:05:21 2026 +0800 ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev [ Upstream commit 402a9d6aab7ac787ab075adeb562c3db8b8f564b ] The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553 Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support") Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d Tested-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/20260903130521.554840-1-eadavis@sina.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 440b66cc7b56ea38e9b878ae88da91992efaa4c4 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:29 2026 -0400 net/sched: ets: clamp quantum in parse and fallback paths [ Upstream commit 1c38487f46b243bfeefec0c0c86023a3904f2214 ] ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1 Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.9 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2297bbf9cf6ece86f1d1f8c683517a994990f9e Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:28 2026 -0400 net/sched: drr: clamp quantum in change class [ Upstream commit 8382abec0f1568d0a5590d75a3df92f23fcf5196 ] drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1 Fixes: 13d2a1d2b032 ("pkt_sched: add DRR scheduler") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.8 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 450348e0ca6b1dfd48d880f4cbd9cda1b859d99f Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:27 2026 -0400 net/sched: pie: clamp psched_mtu in pie_drop_early [ Upstream commit 54370e44c002770ae61fc889f28f699e91616ffc ] pie_drop_early() calls psched_mtu() with no clamp. With mtu=0x80000000 the bytemode divide silently zeroes the drop probability, disabling AQM. Clamp to [1, 1<<20]. Conditions to recreate the bug: CONFIG_NET_SCH_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root pie tc qdisc change dev dummy0 root pie stab data 32768 size_log 15 cell_log 0 Fixes: d4b36210c2e6 ("net: pkt_sched: PIE AQM scheme") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.7 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a328698d046098e6f55b3b1460cac6bab577be58 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:25 2026 -0400 net/sched: hhf: clamp quantum in change and init paths [ Upstream commit eb56a495f59baf6cad5ed80e3ffb9078098b1346 ] hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.5 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4117c528b2de5fdc3e4a7e3626815b616a635cdc Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:24 2026 -0400 net/sched: sfq: clamp quantum in change path [ Upstream commit fb9f88a33c516ea5c0bcd9a22ca288b246b34567 ] sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: e4650d7ae425 ("net_sched: sch_sfq: handle bigger packets") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.4 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff4f3a0f3abd2ded467931d7da7984a68a768e0b Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:23 2026 -0400 net/sched: fq_pie: clamp quantum in change path [ Upstream commit 4864f58c53eb47257d55e01f47d4a9f355f7f970 ] fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.3 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 245ca6c6676331e6e1fe6d10b8bdd339387fae76 Author: Eric Dumazet Date: Thu Apr 18 07:32:44 2024 +0000 net_sched: sch_fq_pie: implement lockless fq_pie_dump() [ Upstream commit 13a9965de32457d59aa3162d657aa4c5e512c146 ] Instead of relying on RTNL, fq_pie_dump() can use READ_ONCE() annotations, paired with WRITE_ONCE() ones in fq_pie_change(). Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: 4864f58c53eb ("net/sched: fq_pie: clamp quantum in change path") Signed-off-by: Sasha Levin commit e3ee194a790896fa92fea20b5385a354be2f2c12 Author: Yael Chemla Date: Wed Sep 2 22:35:14 2026 +0300 net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put [ Upstream commit 7ee07f601f8f507c9faf25c68a49396ab8950596 ] In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree. Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push actions") Signed-off-by: Yael Chemla Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193514.3668880-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6190e71e9faf33ece7918e91c9b4a13319c24165 Author: Carolina Jubran Date: Wed Sep 2 22:32:24 2026 +0300 net/mlx5e: Fix ETS zero BW reporting when one TC holds 100% [ Upstream commit e7ee89740800a1cf253713e9249c3ee9203ebe91 ] When ETS TCs with zero bandwidth are configured, the driver programs the firmware using an alternate representation. On get, it needs to recognize that representation so those TCs can be translated back and reported as 0% bandwidth. The existing detection relied on the programmed bandwidth because it was enough to identify this representation. However, when a single ETS TC owns 100% of the bandwidth, its firmware representation becomes the same as a strict-priority TC, causing zero-bandwidth ETS TCs to be reported with non-zero bandwidth values. Use the cached TSA instead to distinguish the ETS and strict-priority cases. Fixes: be0f161ef141 ("net/mlx5e: DCBNL, Implement tc with ets type and zero bandwidth") Signed-off-by: Carolina Jubran Reviewed-by: Alex Lazar Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193224.3668743-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 92f697fc961fb25f3e46ee9efd954620a6345116 Author: Shahar Shitrit Date: Wed Sep 2 19:46:33 2026 +0300 net/mlx5e: Fix setting RS FEC after remapping [ Upstream commit b9d755c5a37519fb1354034db1dfeb30e1ba6856 ] When a user sets a FEC mode via ethtool, the driver maps the ethtool FEC type to the lowest mlx5 bit of that type. For RS FEC, this is MLX5E_FEC_RS_528_514 (bit 2). The driver then checks whether this bit is supported by at least one link mode by inspecting the fec_override_cap fields via mlx5e_fec_in_caps(), and returns -EOPNOTSUPP if not. This check is incorrect. RS FEC has three supported hardware variants: RS_528_514 (bit 2), RS_544_514_INTERLEAVED_QUAD (bit 4), and RS_544_514 (bit 7). mlx5e_remap_fec_conf_mode() already remaps bit 2 to the appropriate RS variant per link mode when writing the admin fields, but the early capability check is done against the raw unmapped bit. As a result, a device that supports RS_544_514 or RS_544_514_INTERLEAVED_QUAD but not RS_528_514 will incorrectly reject the user's RS FEC request. Remove the early support check from mlx5e_set_fec_mode() and fold it into the existing write loop, checking caps against the remapped policy per link mode. Return -EOPNOTSUPP before the final register write if no link mode accepted the policy. Fixes: 2608a2f831c4 ("net/mlx5e: Fix return status when setting unsupported FEC mode") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4c5df7b130518cc2e85426cfffc871affc22aef Author: Thorsten Blum Date: Sun Aug 9 18:24:01 2026 +0200 powerpc/kexec_file: Use inclusive range checks in add_usable_mem() [ Upstream commit c6755be4838d6ccd641effbcdc3d917b82631ff9 ] add_usable_mem() adds usable memory ranges for the kdump kernel. The ranges are inclusive, but the partial overlap check uses exclusive comparisons. This skips ranges with base == loc_end or end == loc_base. Use inclusive comparisons instead. Fixes: 7c64e21a1c5a ("powerpc/kexec_file: Restrict memory usage of kdump kernel") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260809162403.18142-2-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit 24d02c909a1725ab9eceb92db7d02e4e841f17ca Author: Jamal Hadi Salim Date: Wed Sep 2 17:29:08 2026 -0400 net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations [ Upstream commit 66ab4c59b74db7ab53a1c9083feaaede393a96a0 ] Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The "> S16_MAX" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively). Fixes: 6a643ddb5624 ("net: introduce helper dev_change_tx_queue_len()") Reported-by: Vega Closes: https://lore.kernel.org/netdev/20260828121902.66837-1-jhs@mojatatu.com/ Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00c7f4b8144e535ffb931ad45942a1bd1315b882 Author: Seungwon Bae Date: Thu Sep 3 00:59:56 2026 +0900 vxlan: reject dynamic fdb entries that reference a nexthop id [ Upstream commit 98fc57d167446b95b4e719815fe79edef93f8e7a ] The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the "dynamic" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future. Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Suggested-by: Ido Schimmel Signed-off-by: Seungwon Bae Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260902155956.296699-1-qotmddnjs@ajou.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0c1ce6ef4cefe568e19afa83f543caa3c3c0873 Author: Jason Winter Date: Wed Sep 2 10:40:41 2026 +0200 net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow [ Upstream commit 5d50e90add8b4a978395e893e81954d19d58a7c5 ] The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is } else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check. Fixes: ca139d76b0d9 ("cx82310_eth: re-enable ethernet mode after router reboot") Signed-off-by: Jason Winter Link: https://patch.msgid.link/BESP194MB283265DDDC63B6B78D8D34FBB8B72@BESP194MB2832.EURP194.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e4bfc5f0b66feb22cba821303fc25ca22cd0887 Author: Jakub Kicinski Date: Wed Sep 2 20:26:10 2026 -0700 net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size [ Upstream commit b1fffc273112e7284c5b705e186b43b5770cd3d5 ] mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached. Fixes: da7dc8755304 ("net: dsa: mv88e6xxx: add RXNFC support") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca49c526291d7cd3a5cb49b0edd7f50a5ae7176e Author: Jakub Kicinski Date: Wed Sep 2 20:26:07 2026 -0700 net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size [ Upstream commit cdb719f4b8596d9ccee2d56d204c2c4dce982f46 ] bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc") Reviewed-by: Jonas Gorski Reviewed-by: Florian Fainelli Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7796fed40c4343c1937d198fe6d2078da2c57459 Author: Eric Dumazet Date: Thu Sep 3 14:39:40 2026 +0000 bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit() [ Upstream commit 1746ef2e2df2ad71c66eca56364d56bde284523b ] In bond_do_alb_xmit() and rlb_arp_xmit(), make sure to unclone skb head via skb_cow_head() before modifying the source MAC address (Ethernet header and ARP payload) to avoid silent corruption if the skb is shared or cloned. Avoid caching the header pointers across skb_cow_head(). In rlb_arp_xmit(), only modify arp->mac_src if it differs from tx_slave->dev->dev_addr to avoid an unnecessary copy and head reallocation. Also, we should not assume mac header is set in output path. Use skb_eth_hdr() instead of eth_hdr() to fix the issue, and remove now redundant skb_reset_mac_header() calls. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Cc: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260903143940.1180513-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5756450c9a702da0efb4a993d0a6766b965736f3 Author: Jiayuan Chen Date: Tue Sep 1 18:47:37 2026 +0800 bpf: Fix NULL-ptr-deref in btf_var_show() [ Upstream commit 5403a383f52fc0905703b488f7c3db4b2447dc58 ] btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show(). Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper") Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-4-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cf528f2d7a0a54f2a3c6d439cfa3c8d7dfe90d8d Author: Jiayuan Chen Date: Tue Sep 1 18:47:36 2026 +0800 bpf: Fix NULL-ptr-deref when showing a void BTF type [ Upstream commit 4ea508b9ebd78bce7f212166d2e2cba66b875f08 ] btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A "const void" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a "const void" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the "" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual. Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper") Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ddfff1cec52b7deec6c770ba85de4dab6221d0a2 Author: Takashi Iwai Date: Thu Sep 3 12:38:51 2026 +0200 ALSA: caiaq: Fix potential double-free at error path [ Upstream commit 3b26ceef88c110f4d188387cffa0df78657be904 ] The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared. Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 60ad97e1fbe7009eeb9631a238503f64e44e7b75 Author: Lorenzo Bianconi Date: Mon Aug 31 19:06:38 2026 +0200 net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup() after reset [ Upstream commit 6b8fed2675fb75d23e6cf2b7e49c94926e884b34 ] The core software reset issued in stmmac_init_dma_engine() during ndo_open() callback clears the MTL RX packet parser registers, but stmmac_rxp_config() is only invoked from the cls_u32 add/delete paths. After an ifdown/ifup cycle the hardware therefore runs with the default all-pass table while priv->tc_entries still reports the filters as installed. Re-apply the RX packet parser table from priv->tc_entries in stmmac_hw_setup(), right after the software reset, so the filters are restored when the interface is brought up again. Fixes: 4dbbe8dde848 ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260831-stmmac_tc_cls32_reconfigure-v1-1-21cb459e64ae@oss.qualcomm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f777c602d3e15d3414b53f760147687bd56b03f2 Author: Allison Henderson Date: Fri Aug 28 15:39:21 2026 -0700 net/rds: don't let rds_conn_shutdown() consume a concurrent drop [ Upstream commit 260c6308fe2e19ad519389d44d582e292aecc3af ] rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally. Fixes: e97656d03ca0 ("rds: tcp: allow progress of rds_conn_shutdown if the rds_connection is marked ERROR by an intervening FIN") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-8-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7f4f21e4439df30d9aca9fb3bac38191a2f34729 Author: Håkon Bugge Date: Fri Aug 28 15:39:20 2026 -0700 net/rds: acquire the fastpath locks in rds_conn_shutdown() [ Upstream commit 813f3582ac7ae9f60f917937d54660e0952d5f2d ] rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them ("rds: Make sure transmit path and connection tear-down does not run concurrently"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on the allocation-failure fallback where a path shares rds_wq, the work items simply serialize). Nor is the blocking wait itself new: rds_tcp_reset_callbacks() has waited on RDS_IN_XMIT from the krdsd work item since commit 335b48d980f6 ("RDS: TCP: Add/use rds_tcp_reset_callbacks to reset tcp socket safely"); this patch stretches its worst case from a sender's batch to the teardown's drain. The alternative to parking is the accept path racing the teardown, which is what these patches close; making the teardown itself non-blocking is a separate item. One observable side effect: the SENDING flag reported by rds-info has always mirrored RDS_IN_XMIT, so it now also covers the window where teardown owns the bit. The comments that describe the old sample-based handshake or name rds_send_xmit() as the only other holder of these bits - in rds_send_xmit(), above rds_conn_path_reset(), in rds_ib_recv_refill() and in rds_tcp_reset_callbacks() - are updated to match. For anyone backporting this patch standalone: it depends on "net/rds: clear cp_flags bits individually in rds_conn_path_reset()" and "net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()" earlier in this series. Without the former, the blanket cp_flags clear in rds_conn_path_reset() would drop both held bits in the middle of the teardown; without the latter, rds_tcp_reset_callbacks() would still sample t_sock without owning RDS_IN_XMIT. "net/rds: use clear_bit_unlock() in release_refill()" is needed for the refill side's release to pair with the acquire added here, and the follow-up "net/rds: don't let rds_conn_shutdown() consume a concurrent drop" completes the teardown-state handling for the waiter this patch parks; a backport should carry all four. Fixes: 0f4b1c7e89e6 ("rds: fix rds_send_xmit() serialization") Signed-off-by: Håkon Bugge [achender: reimplement for net-next shutdown path: acquire the existing RDS_IN_XMIT/RDS_RECV_REFILL bit locks in rds_conn_shutdown() and release after teardown; update comments and commit message] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-7-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 670af4e4a4de5e6bb5daee3838485571a0caa5fa Author: Allison Henderson Date: Fri Aug 28 15:39:19 2026 -0700 net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() [ Upstream commit 02c5f9dc2efd823e061954d564ce00bacd1bebeb ] rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them. Fixes: 335b48d980f6 ("RDS: TCP: Add/use rds_tcp_reset_callbacks to reset tcp socket safely") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-6-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b6a402b07485353db047f07c0e8fffa27118442a Author: Gerd Rausch Date: Fri Aug 28 15:39:18 2026 -0700 net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown [ Upstream commit e8e60d74fec49ccae2aea9b04a6eb162feb8d9af ] rds_tcp_reset_callbacks() resolves a duelling SYN by storing RDS_CONN_RESETTING into cp_state unconditionally. Nothing serializes that store against the shutdown path: rds_tcp_accept_one() checks for RDS_CONN_CONNECTING or RDS_CONN_ERROR under t_conn_path_lock, but neither rds_conn_path_drop(), which forces RDS_CONN_ERROR, nor rds_conn_shutdown(), which moves the path to RDS_CONN_DISCONNECTING under cp_cm_lock, takes that lock. The store can therefore land on top of a shutdown that is already in progress, or that gets queued right after the accept-side check. When it does, the shutdown worker's final DISCONNECTING -> DOWN transition fails and the path goes through rds_conn_path_error() and a second drop/shutdown cycle instead of a clean reconnect, tearing down the socket the accept path has just installed. Before commit ad22d24be635 ("net/rds: No shortcut out of RDS_CONN_ERROR") a path found in RDS_CONN_RESETTING even made rds_conn_shutdown() bail out altogether. Make the transition conditional: move CONNECTING -> RESETTING (or stay in RESETTING from an earlier duel), and drop the path in any other state. The drop has side effects of its own: it replaces the shutdown's RDS_CONN_DISCONNECTING (or RDS_CONN_ERROR) with RDS_CONN_ERROR and queues one more cp_down_w run. The difference is that rds_conn_shutdown() accepts RDS_CONN_ERROR in its final transition to RDS_CONN_DOWN, so the shutdown in flight completes normally instead of through rds_conn_path_error(); the extra down-work pass then finds the path already down and falls through to the reconnect check, or catches a reconnect that has already started and restarts it. The accept path still installs the new socket, rds_connect_path_complete() then fails its RESETTING -> UP transition and drops it: the raced socket ends up torn down as it does today. The comment at that call site, which promised that rds_connect_path_complete() marks the path RDS_CONN_UP, is updated to name this outcome as well. The state can change again between the failed transitions and the drop. That is inherent to rds_conn_path_drop(), which the socket state-change callbacks also call unconditionally, and costs at most one extra drop/reconnect cycle. Based on Oracle UEK commit "net/rds: Don't force state RDS_CONN_RESETTING" by Gerd Rausch. Fixes: 9c79440e2c5e ("RDS: TCP: fix race windows in send-path quiescence by rds_tcp_accept_one()") Signed-off-by: Gerd Rausch [achender: port to net-next: use the two-argument rds_conn_path_transition()/rds_conn_path_drop() and rewrite the changelog for the upstream shutdown path] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-5-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c9a7c1eb0ad41dcf004a9e870e452cafedcd9172 Author: Allison Henderson Date: Fri Aug 28 15:39:17 2026 -0700 net/rds: clear cp_flags bits individually in rds_conn_path_reset() [ Upstream commit 103c4b13c4f50322910078d1c02f29334a574122 ] rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion ("net/rds: Preserve essential connection state flags"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit "net/rds: Preserve essential connection state flags" by Gerd Rausch. Fixes: 00e0f34c6166 ("RDS: Connection handling") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-4-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 82d0df24b95f805e47e5b97edab63f7d962a5b41 Author: Allison Henderson Date: Fri Aug 28 15:39:16 2026 -0700 net/rds: use clear_bit_unlock() in release_refill() [ Upstream commit 17c4476dbb9c3bfd34193a6c22f2c3da8747134a ] release_refill() drops the RDS_RECV_REFILL bit with a plain clear_bit(). clear_bit() has no ordering semantics, and the smp_mb__after_atomic() that follows it sits on the wrong side for a lock release: it orders the clear against the waitqueue_active() load below it, but does nothing to order the refill critical section's ring and descriptor stores before the clear itself. That matters once connection teardown owns RDS_RECV_REFILL as a lock across the transport shutdown and path reset, rather than sampling it clear, which "net/rds: acquire the fastpath locks in rds_conn_shutdown()" later in this series arranges: on a weakly ordered architecture the teardown can win the bit and start the shutdown and reset while some of the refill's stores are not yet visible to it. The same gap existed under the sample-based scheme - a waiter that saw the bit clear had no guarantee it also observed the refill's stores - but taking the bit as a lock makes the missing release pairing load-bearing. Switch to clear_bit_unlock(), which orders the critical section before the release, and replace the open-coded barrier-plus-waitqueue_active() with wq_has_sleeper(), whose internal full barrier keeps the store-buffering guarantee between clearing the bit and checking for sleepers. This mirrors what "net/rds: use wq_has_sleeper() in release_in_xmit()" does for RDS_IN_XMIT. The fast-path acquire side, acquire_refill(), uses test_and_set_bit(), a full-barrier RMW that pairs with this release. The teardown at this point in the series still samples the bit, so on its own this change is release-side hardening; the shutdown-conversion patch named above makes the teardown acquire the bit with the same RMW, completing the pairing at the end of the series. Fixes: 73ce4317bf98 ("RDS: make sure we post recv buffers") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6f552364d97cf4005c7a58f11c9f79e14e269865 Author: Allison Henderson Date: Fri Aug 28 15:39:15 2026 -0700 net/rds: use wq_has_sleeper() in release_in_xmit() [ Upstream commit 6d0c8b7073913011459cf968cbbadd341e166bc3 ] release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier. Fixes: 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1ded242135071769902778dbab081e3fc09730f Author: Eric Dumazet Date: Mon Aug 31 20:30:42 2026 +0000 bonding: do not clear curr_active_slave prematurely when releasing all slaves [ Upstream commit af602c7aa5fedc9be3043244017aef4f26c96b70 ] When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave). Fixes: 0896341a44bf ("bonding: fix bond_release_all inconsistencies") Signed-off-by: Eric Dumazet Acked-by: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260831203042.164466-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38305e1b8b1ec27eef8f2d4e461e3b6c8624d494 Author: Henry Martin Date: Wed Aug 26 11:00:09 2026 +0800 tracing/probes: Fix use-after-free on field name/type of events with multiple probes [ Upstream commit 86b7a239ec6b14a7544200ede85474c6f5526049 ] The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab. Link: https://lore.kernel.org/all/20260826030009.1855331-1-bsdhenrymartin@gmail.com/ Fixes: ca89bc071d5e4 ("tracing/kprobe: Add multi-probe per event support") Signed-off-by: Henry Martin Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 9ae0a87e6f513293677fe286729fbae34d592215 Author: Joas Antonio dos Santos Date: Tue Aug 18 06:31:43 2026 -0700 netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() [ Upstream commit e8f8231824b5815f57ce62cba116e511b10196de ] sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own "no more data" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both "no more data" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for. Fixes: ea45f12a2766d ("[NETFILTER]: nf_conntrack_sip: parse SIP headers properly") Signed-off-by: Joas Antonio dos Santos Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ae38b2ae16f709c0193e1b4340bde26ef3e2687d Author: Kyle Zeng Date: Mon Aug 10 15:13:47 2026 -0700 ipvs: fix reversed sequence option serialization [ Upstream commit b04578b74f2d3755548fe9e829e3b2a6c6f966a1 ] hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks. Fixes: 986a07579533 ("IPVS: Backup, Change sending to Version 1 format") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d0284d974be46a0a06068f930c84039d540ae8ed Author: Qu Wenruo Date: Thu Aug 20 18:28:48 2026 +0930 btrfs: do not force reloc root creation during qgroup_account_snapshot() [ Upstream commit cacf35832292997018837e484283f95a9301ebf5 ] [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS="-O quota", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 item 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 extent refs 1 gen 222 flags 2 ref#0: tree block backref root 266 [ Skip the tree dump ] item 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 extent refs 1 gen 162 flags 258 ref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With "ref_verify" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 BTRFS error (device dm-2): Ref action 2, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 18446744073709551615 btrfs_force_cow_block+0x327/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_lookup_file_extent+0x4d/0x70 [btrfs] btrfs_drop_extents+0x151/0xf00 [btrfs] insert_reserved_file_extent+0xfe/0x3e0 [btrfs] btrfs_finish_one_ordered+0x549/0xc40 [btrfs] btrfs_work_helper+0xde/0x350 [btrfs] process_one_work+0x198/0x380 worker_thread+0x1c8/0x330 kthread+0xee/0x120 ret_from_fork+0x28f/0x310 ret_from_fork_asm+0x11/0x20 BTRFS error (device dm-2): Ref action 1, root 273, ref_root 0, parent 4594335744, owner 0, offset 0, num_refs 1 __btrfs_mod_ref+0x1c5/0x2d0 [btrfs] btrfs_copy_root+0x262/0x390 [btrfs] create_reloc_root+0xb9/0x370 [btrfs] btrfs_init_reloc_root+0xb0/0x1b0 [btrfs] record_root_in_trans+0xa6/0xd0 [btrfs] create_pending_snapshot+0x383/0xf00 [btrfs] create_pending_snapshots+0x9b/0xc0 [btrfs] btrfs_commit_transaction+0x280/0xeb0 [btrfs] prepare_to_relocate+0x147/0x200 [btrfs] relocate_block_group+0x6b/0x5e0 [btrfs] btrfs_relocate_block_group+0x92c/0x2380 [btrfs] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs] btrfs_balance+0xa2c/0x19c0 [btrfs] btrfs_ioctl+0x2839/0x2d30 [btrfs] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 The above shows the direct cause, Ref action 3 is the oldest operation, which shows the tree block is created by COW. Then ref action 2 shows it's COWed away, by a metadata update, meaning the tree block is already released, should not be referred any more. Then the final one, is trying to create a reloc tree for subvolume 273, and that reloc root creation is referring to the already dropped tree block. The root cause is that, during qgroup_account_snapshot(), we are calling record_root_in_trans() with "force = true". So if the root has no reloc root, we will create one, but at that timing it's already too late. Normally reloc root should be created before the commit and current roots diverge, to avoid the same problem we are hitting. But during relocation initialization, we are committing the current running transaction, with a new reloc_control attached halfway. And if qgroup is enabled, the record_root_in_trans() with "force = true" calls will force reloc root creation even if we do not and should not create reloc root at that timing. [FIX] Do not force reloc root creation during record_root_in_trans() with "force = true" cases, which is only called by qgroup_account_snapshot(). If we're really under relocation, the reloc root should be created way early, before the commit and current root diverge. If the root has no reloc tree yet, it means we're still initializing the reloc, and do not need a reloc root. So skipping the reloc tree creation in qgroup_account_snapshot() should be safe. Link: https://bugzilla.suse.com/show_bug.cgi?id=1275740 Fixes: 4d31778aa2fa ("btrfs: qgroup: Fix root item corruption when multiple same source snapshots are created with quota enabled") Assisted-by: LLM (initial analysis, but incorrect conclusion with too many burnt tokens) Tested-by: Disha Goel Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f332b4d407d1a8a7f6c68eb2ae691e07229bce3b Author: Josef Bacik Date: Fri Mar 12 15:25:12 2021 -0500 btrfs: return an error from btrfs_record_root_in_trans [ Upstream commit 03a7e111a94961092e2832a6259d39c8c01d6def ] We can create a reloc root when we record the root in the trans, which can fail for all sorts of different reasons. Propagate this error up the chain of callers. Future patches will fix the callers of btrfs_record_root_in_trans() to handle the error. Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Signed-off-by: David Sterba Stable-dep-of: cacf35832292 ("btrfs: do not force reloc root creation during qgroup_account_snapshot()") Signed-off-by: Sasha Levin commit 1835a08e4fc6cccf0d952dadd722bdc209fba82e Author: Linus Walleij Date: Wed Sep 2 09:55:59 2026 +0200 ASoC: ux500: Program the MSP FIFO watermarks [ Upstream commit 2519439b4b5f6ee95879b1a44fc373127291b1e4 ] The DMA engine is configured for four-element bursts, but the MSP driver never programs the FIFO watermark register and instead depends on its previous or reset value. The DB8500 DMA request protocol requires the peripheral watermark to match the DMA packet size. Program four-element receive and transmit watermarks when configuring the first direction, before enabling MSP DMA requests. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-9-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7cb12bea794044980cd1e9736f580215071a9e24 Author: Linus Walleij Date: Wed Sep 2 09:55:56 2026 +0200 ASoC: ux500: Request the MSP MMIO resource [ Upstream commit 4fb67925f33ad789e9e00903a73306ed40f7ae32 ] A bare devm_ioremap() neither reserves the register range nor preserves the platform resource error. This permits another driver to claim the same range and reports every mapping failure as an allocation failure. Use the managed platform resource helper, retaining the resolved resource only to derive the DMA register address. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-6-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 36a0dbf4b87340144bd887dd715b1bba9ada2b97 Author: Arnd Bergmann Date: Wed Jan 18 17:10:48 2023 +0100 ASoC: ux500: remove stedma40 references [ Upstream commit aafe9375b386010e28614f58499d199250a16874 ] ux500_pcm_request_chan() is never called because the dma channels are already set up from DT. Remove this, along with the ux500_msp_dma_params structure. Signed-off-by: Arnd Bergmann Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20230118161110.521504-4-arnd@kernel.org Signed-off-by: Mark Brown Stable-dep-of: 4fb67925f33a ("ASoC: ux500: Request the MSP MMIO resource") Signed-off-by: Sasha Levin commit eef9bbcab498891d862d3b79f8ea190f6cdae9d2 Author: Linus Walleij Date: Wed Sep 2 09:55:54 2026 +0200 ASoC: ux500: Validate MSP DAI configuration [ Upstream commit 9ccbacf5a0120964fc1ffacb8151e3347bee9287 ] Installing channel constraints from hw_params is too late to affect the parameters being committed. The driver consequently accepts channel counts which disagree with the I2S or TDM setup. It also silently truncates out-of-range slot masks and accepts inverted bit clock formats which prepare then rejects. Validate the selected channel count directly, reject invalid masks before changing cached TDM state, and implement all four standard clock and frame inversion combinations. Use the requested format in validation diagnostics. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-4-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 970dcc4d1674ca07fb1f3bbb68fcdd9622950b4c Author: Linus Walleij Date: Wed Sep 2 09:55:53 2026 +0200 ASoC: ux500: Correct MSP frame and bit clock setup [ Upstream commit 94c18cea657c48680e4ee20b635b6c01f3eb352e ] FRPER plus one is the number of bit clocks in a frame. It must follow the configured slot count and width. The legacy rate-dependent constants produce malformed frames; notably, a 16-slot, 16-bit frame is programmed as 278 rather than 256 clocks. Derive the frame period from the TDM geometry and use the real functional clock rate. Validate that the requested bit clock has an exact, representable divider, program SCKDIV as divider minus one, and report the resulting bit clock using that same divisor. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-3-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit be9224c64705755a1ef99ef517780c183644b560 Author: Linus Walleij Date: Wed Sep 2 09:55:52 2026 +0200 ASoC: ux500: Propagate MSP setup errors [ Upstream commit 3415421a2b0bc4e32bb5a9df24ed7863512d47a7 ] The prepare callback continues with a partly initialized configuration when format setup fails. Probe likewise tests the allocated pointer instead of the return value, so an MMIO resource or mapping failure can be ignored after allocation succeeds. Return configuration failures from prepare and test the MSP initialization result directly. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-2-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd0bc8d64a96ad9fa44f83bf9043f330da34db28 Author: Arnd Bergmann Date: Wed Jan 18 17:10:47 2023 +0100 ASoC: ux500: remove platform_data support [ Upstream commit 1766ac5248063c25d1fe46e04bb936c46313ed89 ] The platform data definition for ux500 sound devices was removed six years ago after the DT conversion was completed, see commit 4b483ed0be8b ("ARM: ux500: cut some platform data"). Remove some leftover bits in the ASoC driver and just assume that it always gets probed using DT. Signed-off-by: Arnd Bergmann Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20230118161110.521504-3-arnd@kernel.org Signed-off-by: Mark Brown Stable-dep-of: 3415421a2b0b ("ASoC: ux500: Propagate MSP setup errors") Signed-off-by: Sasha Levin commit 631e2b404828f80d83358cbc7db6d32d5e0c2a23 Author: Linus Walleij Date: Wed Sep 2 09:55:51 2026 +0200 ASoC: ux500: Fix MSP stream lifecycle handling [ Upstream commit c37ba8fe00f264eee2fd18b0bff7c5f188136c51 ] The trigger stop path drops the direction busy flag even though ALSA still owns the stream until shutdown. A later trigger cannot reliably restart it, shutdown may leave the block configured, and a second stream may overwrite shared duplex configuration. Keep configured and running directions as separate state. Program shared settings only for the first direction, require a compatible configuration for the other half of a duplex stream, and enable the frame generator only while a provider stream is running. Also fix the RX-disable direction test and preserve the other direction multichannel setup. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-1-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a57fb1d5ce8f316b81bbb60e6df245ebc816ffc Author: Guanghui Yang <3497809730@qq.com> Date: Mon Aug 10 20:16:04 2026 +0800 btrfs: detach failed sprout device from transaction update list [ Upstream commit c93b3c43df561cd9f592cee20ae058b563f9e5b6 ] When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it. Fixes: bbbf7243d62d ("btrfs: combine device update operations during transaction commit") Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f6f2ed327d151eb3a0fcac40aea887d5e7840ee8 Author: wangdicheng Date: Mon Aug 24 14:35:06 2026 +0800 ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits [ Upstream commit 0c06c4ce0206290c9a934a1e7196aaa86adfe018 ] disable_pdm_interrupts() uses |= ~PDM_DMA_INTR_MASK which sets all bits except the PDM DMA interrupt bit instead of clearing only the PDM DMA interrupt bit. Use &= ~PDM_DMA_INTR_MASK to clear only the target bit. Fixes: f621a3676d3f ("ASoC: amd: add ACP3x PDM platform driver") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260824063507.483784-1-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0843298b159599ee7bc6d14800efdb4bc7349706 Author: Hui Su Date: Fri Aug 7 23:09:55 2026 +0800 staging: fbtft: make dirty_lock IRQ-safe [ Upstream commit f576944a59f31bcffff121117ebf452c5dd162b7 ] fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Hui Su Link: https://lore.kernel.org/lkml/20260804173712.176017-1-sh_def@163.com/ Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260807150953.2811933-3-sh_def@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3e0cad1432a0c0564f5076bab16f1aa4c0474be4 Author: Kuniyuki Iwashima Date: Sun Aug 30 18:09:12 2026 +0000 af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). [ Upstream commit 73e594c19b4f815d8343461cec7074c4713bbde7 ] syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Reported-by: syzbot+73df3f89e1e13089e466@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a946ffa.1d9ded08.62e62.0123.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260830180915.260225-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f463c4786cf27376de7dfc0833a12e924a98f698 Author: Eric Dumazet Date: Fri Aug 28 14:17:27 2026 +0000 ipv6: sr: restore network header before routing and forwarding [ Upstream commit 975b5b067f525a1b1338c4a3bee1c46545801518 ] ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back. Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)") Reported-by: TencentOS Corvus AI Reported-by: Jun Yang Reported-by: Fourie Zhang Closes: https://lore.kernel.org/netdev/20260817104128.22681-1-juny24602@gmail.com/ Closes: https://lore.kernel.org/netdev/20260827092345.2301937-1-fouriezhang@tencent.com/ Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828141727.2372570-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 02b6b721c74ed413beb1f74ed208477965a76fd8 Author: Qingfang Deng Date: Fri Aug 28 15:32:36 2026 +0800 ppp: ppp_async: simplify tty disc_data access [ Upstream commit 9feb069e5ed03582fbf6272539f1caa2a17dc6d5 ] tty_ldisc_hangup() invokes the hangup callback while holding only a read lock on tty->ldisc_sem, so it can run concurrently with other line discipline callbacks. This currently forces async PPP to maintain separate lifetime protection around tty->disc_data. Line discipline close is called under the write lock during hangup processing. Remove the hangup callback and rely on close for teardown, as done for SLIP by commit 23c53269f2ba ("slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()"). This serializes teardown with all other line discipline operations. disc_data_lock, refcount and completion are redundant with that serialization. Remove them and access tty->disc_data directly. This also eliminates a lockdep warning reported by syzbot. The warning does not indicate a real deadlock because the write side runs only in process context with hardirqs disabled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+8e808eb853386f575d86@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000002fbad30611e25849@google.com/ Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828073245.126804-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6679832050db5bf91c495a81f4359941ae8e458f Author: Jiri Slaby Date: Tue Sep 14 11:11:22 2021 +0200 tty: make tty_ldisc_ops::hangup return void [ Upstream commit 28f194da4a2c4d431552025a4386edaffab181bd ] The documentation says that the return value of tty_ldisc_ops::hangup hook is ignored. And it really is, so there is no point for its return type to be int. Switch it to void and all the hooks too. Cc: Dmitry Torokhov Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Paul Mackerras Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Peter Ujfalusi Acked-by: Dmitry Torokhov Acked-by: Mark Brown Acked-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210914091134.17426-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 9feb069e5ed0 ("ppp: ppp_async: simplify tty disc_data access") Signed-off-by: Sasha Levin commit 2a277a4855404f8dd56211f5bbf061afe987b0d9 Author: Linus Walleij Date: Mon Aug 31 22:29:09 2026 +0200 ASoC: ab8500: Validate and program TDM slots correctly [ Upstream commit 85cef7e2004ef5c1a715feaddb55d3f3d27bac0a ] The interface clock ratio is selected from the slot count alone, ffs() and fls() produce one-based hardware slot numbers, eight-channel mode does not program any mappings, and all register errors are ignored. Invalid masks can also leave a partially programmed interface. Validate the complete configuration first, derive the supported BCLK ratio from slots times slot width, use zero-based slot indices, program deterministic eight-channel maps, and propagate register failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-4-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a9c28b0a2bd2426ecf0e18400206e37dcf0bdfb0 Author: Linus Walleij Date: Mon Aug 31 22:29:08 2026 +0200 ASoC: ab8500: Correct digital interface format setup [ Upstream commit f98785adf004db6b1c9f4cea9dadae7b800db72f ] The codec programs I2S as an undelayed left-aligned format, although the hardware manual defines delayed left-aligned as I2S compatible. It also enables the master generator when the codec is a clock consumer, changes registers before the complete format has been validated, and discards register I/O errors. Build all three interface register values before writing them, use the required one-bit I2S delay, only run the master generator for a provider configuration, and propagate write failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-3-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c0d5679a3d6a85d83be0181ed63321bc1b382b0 Author: Mark Brown Date: Thu Sep 16 15:13:35 2021 +0100 ASoC: ab8500: Update to modern clocking terminology [ Upstream commit ef92ed2623ead917e4f10465451aa12cd7977241 ] As part of moving to remove the old style defines for the bus clocks update the ab8500 driver to use more modern terminology for clocking. Signed-off-by: Mark Brown Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210916141335.43818-1-broonie@kernel.org Signed-off-by: Mark Brown Stable-dep-of: f98785adf004 ("ASoC: ab8500: Correct digital interface format setup") Signed-off-by: Sasha Levin commit 2b427d572f93bdf0f565d86b003a5c0746eb2402 Author: Linus Walleij Date: Mon Aug 31 22:29:07 2026 +0200 ASoC: ab8500: Repair the DAPM capture graph [ Upstream commit 103fe1a37f040ef6ac9ed1cf33be786149d2bb15 ] The capture stream routes point away from the stream widget. Digital microphone mux routes are unconditional and bypass their enable bits, and several widgets independently own shared AD path enable bits. The dummy ADC and DAC widgets hide the resulting power graph errors. Connect each real AIF widget to the stream and main supply, use the mux item names on digital microphone routes, and model shared AD enables as supplies. Also make the ANC DAPM switch writable. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-2-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2b6e2f3544d433436559ef671f161c008ad8bfc5 Author: Linus Walleij Date: Mon Aug 31 22:29:06 2026 +0200 ASoC: ab8500: Reset the audio block before configuring it [ Upstream commit 8e839bca7793a0b03c005f4b2b0825464290d425 ] ResetAudn is active low, but the codec probe only deasserts it. It also clears Clk32kOut2Dis despite claiming to disable that output, and writes codec registers before releasing reset. Pulse ResetAudn before the first audio-bank access and leave the unused 32 kHz output disabled. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-1-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d37f8dd0e71401d2920cbc09b2bf09d430514601 Author: Gongwei Li Date: Tue Aug 25 10:01:45 2026 +0800 Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout() [ Upstream commit 2deb76c21b81e42b3282224f7dd2046fe73fd1e0 ] wait_on_bit_timeout() returns 0 if the bit was cleared, -EINTR if the process received a signal and the mode permitted wake up on that signal, or -EAGAIN if the timeout elapsed. It never returns 1. Hence the check "err == 1" in mrvl_load_firmware() is dead code: when the waiting task is interrupted by a signal (-EINTR), the code falls into the "else if (err)" branch and misreports it as "Firmware request timeout" with -ETIMEDOUT instead of propagating -EINTR. Fix this by testing for -EINTR so that an interrupted firmware load is properly detected and reported. Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Signed-off-by: Gongwei Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6135c32d7a90175325e64e0f17d79a2074facdc5 Author: Pauli Virtanen Date: Sun Aug 30 15:04:02 2026 +0300 Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM [ Upstream commit 0d77683237270702fa93489ca759c89b4e970554 ] l2cap_ecred_defer_connect() clears FLAG_DEFER_SETUP also for channels with different PID/PSM, which will not be added to the same ECRED_CONN_REQ in any case. Consequently, only one ECRED connection group can work at a time although it appears intended they would be separate for each PID/PSM combination. Fix by clearing FLAG_DEFER_SETUP only for the connections that could be added in the request. Retain test_bit(FLAG_DEFER_SETUP) before calling get_peer_pid as it may be NULL otherwise. Fixes: da49b602f7f7 ("Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ad0f44a3f1f688558ed876a0702bc2c82b0df689 Author: Pauli Virtanen Date: Sun Aug 30 20:11:36 2026 +0300 Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan [ Upstream commit 4ef05db5b08b176a551b4a6287372045998806b0 ] l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ebbf539aa677d46a369f15967bda2e61f14cac57 Author: Colin Ian King Date: Wed Aug 26 14:19:57 2026 +0100 OPP: of: Fix potential multiplication overflow when calculating freq [ Upstream commit e11811a552252740bd396ec38378e9570ee16578 ] The multiplication be32_to_cpup(val++) * 1000 is performed using 32 bit unsigned integers and hence uses a 32 bit multiplication; this will overflow if be32_to_cpup(val++) is greater than 4294967 (which is very unlikely at present). The result is assigned to an unsigned long (which is a 64 bit value on 64 bit systems), so fix this potential overflow by casting the first operand of the multiplication to an unsigned int. Fixes: b496dfbc94ab ("PM / OPP: Initialize OPP table from device tree") Signed-off-by: Colin Ian King Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e6410b2a95f0fa1e17d18e1a0930712a264fda4a Author: James Nugraha Date: Fri Aug 28 09:22:19 2026 +1000 net: amd-xgbe: discard rx packets with bad FCS [ Upstream commit ac8d6b28d48c5d951dcd923d33e461588e762a6d ] amd-xgbe driver currently sets the MAC_RCR.DCRCC bit whenever RX is enabled. This disables hardware FCS validation, causing packets with bad FCS to be accepted unconditionally. This change unsets DCRCC so that packets with bad FCS will be dropped, in-line with typical behaviours of many other network controllers. Tests: - Verified that packets with bad FCS are now dropped. - Verified that receiving packets with bad FCS will increment the `rx_crc_errors` counter. Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver") Signed-off-by: James Nugraha Link: https://patch.msgid.link/20260827232220.69907-1-aslan.jnn@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba54cad229977f4fae6355dbdaf117088414fdd0 Author: Henry Martin Date: Fri Aug 28 12:24:25 2026 +0800 sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration [ Upstream commit 2cb0b0b1ed69430bf73740377ea0a1c44c50db63 ] sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Henry Martin Acked-by: Xin Long Link: https://patch.msgid.link/20260828042431.3873725-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cbf2df9aac4202f9fb0b361a7fe8c79b29fad92c Author: Xin Long Date: Wed Aug 26 15:49:04 2026 -0400 sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START [ Upstream commit 2188569e7e1b0bc3f3b557dc97ab7a02befc11c8 ] The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative. Fixes: 20a785aa52c8 ("sctp: Don't add the shutdown timer if its already been added") Reported-by: Zero Day Initiative Signed-off-by: Xin Long Link: https://patch.msgid.link/9d8f1b5c50329d5ea7c642128d35681abaa9ed20.1787773744.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4fe7aa7e204d78e0df150a7de3a72ecb784324d Author: Victor Nogueira Date: Mon Aug 24 12:39:01 2026 -0300 net/sched: act_api: size the RTM_GETACTION reply from the actions [ Upstream commit e9ca46ebc3262b498626c4095826b8fa034bbf21 ] tca_action_gd() already walks every requested action and accumulates attr_size += tcf_action_fill_size(act), then wraps the result in tcf_action_full_attrs_size(). For RTM_DELACTION that value is handed to tcf_del_notify_msg(), which allocates max(attr_size, NLMSG_GOODSIZE). For RTM_GETACTION it is silently discarded and tcf_get_notify() allocates a fixed NLMSG_GOODSIZE skb instead. Any action whose dump exceeds that fixed budget therefore cannot be read back. For example, act_pedit overruns the budget with 32 actions of four munge keys each, act_police with 32 policers once the optional rate/peakrate/result/avrate attributes are present Fix this by passing attr_size through and allocate the reply the way the add and delete paths do. Note on exposure: RTM_GETACTION is the only one of the three action commands that is not capability checked - tc_ctl_action() requires CAP_NET_ADMIN for RTM_NEWACTION and RTM_DELACTION only - so this turns a fixed NLMSG_GOODSIZE reply into a user sized allocation on an unprivileged path. It is bounded by TCA_ACT_MAX_PRIO actions per request, and tca_action_gd() does not reject duplicate indices, so a single large action can be requested 32 times; an act_bpf program near BPF_MAXINSNS is about 32KB of dump, or roughly 1MB for one request. Creating such an action still requires CAP_NET_ADMIN, and the add and delete paths have sized their skbs this way since the Fixes commit. Should this ever need bounding, GFP_KERNEL_ACCOUNT would charge the reply to the caller's memcg. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824153903.4143642-3-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7f36212fc0a3a735d35d6958c8862e3922453384 Author: Victor Nogueira Date: Mon Aug 24 12:39:00 2026 -0300 net/sched: act_api: budget all shared attributes in notify skbs [ Upstream commit 13eb543cebef6d6c3ec42e31afe3856f51b7126b ] tcf_action_shared_attrs_size() is supposed to return an upper bound on the netlink attributes every action dump emits outside of TCA_ACT_OPTIONS, so that tcf_add_notify_msg(), tcf_del_notify_msg() and friends can allocate an skb large enough for the reply. It has fallen behind the dump path and is now an underestimate for every single action. Attributes, such as, TCA_ACT_IN_HW_COUNT and TCA_STATS_BASIC_HW are emitted unconditionally and never accounted for. TCA_STATS_PKT64, TCA_ACT_USED_HW_STATS, TCA_STATS_RATE_EST, TCA_STATS_RATE_EST64 require specific conditions, but are also not accounted for. Fix the issue by budgeting all of them so that we have a legitimate upper bound. Even tough for of them require specific conditions, they are cheap so, to avoid overcomplicating, we opted to account for them unconditionally as well to account for a real worst case scenario. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824153903.4143642-2-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb679f2911df00763eaa781f9c107f52530739c5 Author: Hongfu Li Date: Thu Aug 20 15:09:44 2026 +0800 selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter [ Upstream commit a8c6daab4b0e276508b7ffdd66c60fd3020a9178 ] cg_run_in_subcgroups() discards its arg and always passes NULL to cg_run(), turning the (void *)100 from test_kmem_dead_cgroups() into NULL so no allocation occurs. This makes test_kmem_dead_cgroups() falsely pass without exercising the "dying cgroup with charged slab" scenario it intends to test. Pass the arg through to cg_run() to fix this. Fixes: 933dc80ec262 ("kselftests: cgroup: add kernel memory accounting tests") Signed-off-by: Hongfu Li Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 975f3cf302bb7d7336df4c630a7c07e12780ad10 Author: Dan Carpenter Date: Thu Aug 13 10:08:09 2026 +0300 drm/virtio: Fix a NULL vs ERR_PTR() bug in virtio_gpu_user_framebuffer_create() [ Upstream commit 94579f24e2b526a04eb41050af0ba018c6f528e7 ] Smatch complains that returning a NULL here will lead to a NULL pointer dereference in drm_mode_addfb2(). Return an error pointer instead. Fixes: dc5698e80cf7 ("Add virtio gpu driver.") Signed-off-by: Dan Carpenter Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/an1tWfHIHwtXd9SO@stanley.mountain Signed-off-by: Sasha Levin commit a60794ee3f453516ab3ed212ba0295ecf890bc8c Author: Jad Keskes Date: Thu Jul 30 15:55:48 2026 +0100 EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation [ Upstream commit 66cc9dec919dd63d8e4b3d386f7aed3ae684e645 ] The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU. Fixes: e27e3dac6517 ("drivers/edac: add edac_device class") Signed-off-by: Jad Keskes Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260730145549.148229-1-inasj268@gmail.com Signed-off-by: Sasha Levin commit 0ceae734f545d28deaa1b3df063228232af1d1bc Author: Xie Yuanbin Date: Tue Jul 28 03:03:22 2026 +0100 ARM: 9484/1: enable interrupts when unhandled user faults are triggered [ Upstream commit e79ca91165d4fd18549c536abdb86101e889052f ] PREEMPT_RT requires interrupts to be enabled when sending signals. When do_DataAbort()/do_PrefetchAbort() triggers unhandled user faults, that is `inf->fn()` return a non-zero value, and the interrupts are not enabled within the hook function, force_sig_fault() will be called with interrupts disabled. This can be triggered by user programs executing the bkpt instruction, with kernel config CONFIG_PERF_EVENTS=n. Enable interrupts in do_DataAbort()/do_PrefetchAbort() when unhandled user faults are triggered to fix the issue. Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") Link: https://lore.kernel.org/20260629123349.134224-1-xieyuanbin1@huawei.com Suggested-by: Russell King Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Linus Walleij Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d0a5f22f3a4d8e342a53d644674813a2c41083ae Author: Sasha Levin Date: Mon Sep 14 20:21:45 2026 -0400 Revert "Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU" This reverts commit 5b3f64156784e38b93c7cf767e6afa06fe0c8989. Signed-off-by: Sasha Levin commit c807404a362cdcd1015288aa3903d45138ca4e3a Author: Sasha Levin Date: Mon Sep 14 20:21:45 2026 -0400 Revert "Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU" This reverts commit 7275e801cc9482bb35a606d3b0c23337f492e92a. Signed-off-by: Sasha Levin commit ba5f0015bfd376d764163045a61c17be75f44dae Author: Raphael Zimmer Date: Mon Sep 14 10:56:19 2026 +0300 libceph: Reject monmaps advertising zero monitors commit 40480eee361ed9676b3f844d532ac28b47251634 upstream. A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the "BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop "log output for unusual values of num_mon" part ] Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Roman Demidov Signed-off-by: Sasha Levin commit 25f354c55b8435d1f51b8a0a05a3cfe429358523 Author: Vlatko Kosturjak Date: Thu Sep 3 08:21:29 2026 +0200 ppp_async: drop the errored frame instead of resetting its headroom [ Upstream commit 8dc5d98a16fa23c00999aecf10018c9f69fa5bf4 ] ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: *(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: err: if (skb) { /* make skb appear as freshly allocated */ skb_trim(skb, 0); skb_reserve(skb, - skb_headroom(skb)); } ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied. Fixes: 6722e78c9005 ("[PPP]: handle misaligned accesses") Suggested-by: Eric Dumazet Signed-off-by: Vlatko Kosturjak Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/apkR6ZU+tqP2C3Fl@griffin.linux.hr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 178f1e19d1b17458008cb3dc4812762fbd208086 Author: Geert Uytterhoeven Date: Thu Nov 6 14:33:49 2025 +0100 clk: at91: pmc: #undef field_{get,prep}() before definition [ Upstream commit dbfe51513aae6bace00cc390e11cb486a64a63d2 ] Prepare for the advent of globally available common field_get() and field_prep() macros by undefining the symbols before defining local variants. This prevents redefinition warnings from the C preprocessor when introducing the common macros later. Suggested-by: Yury Norov Signed-off-by: Geert Uytterhoeven Acked-by: Alexandre Belloni Acked-by: Stephen Boyd Acked-by: Claudiu Beznea Signed-off-by: Yury Norov (NVIDIA) Signed-off-by: Sasha Levin commit 5afb5b15966bb9e77663dc19d6f01110fd7ecc98 Author: Rudi Heitbaum Date: Wed Aug 5 15:21:02 2026 +0000 ASoC: rt5645: Perform the initial jack detect at probe [ Upstream commit 54b279699279411c77c8afbc73b83c70740a7303 ] The only initial jack detect is the rt5645_irq(0, rt5645) at the end of rt5645_set_jack_detect(). A card described with simple-audio-card has no machine driver to call that, so jack state is only ever sampled from an edge on hp-detect-gpios. A headphone already in the socket at boot is therefore never noticed, and the card is silent with every mixer control set correctly. rt5645_jack_detect() is what force enables the "LDO2" and "Mic Det Power" supplies that the "HP amp" widget depends on, and what programs RT5645_CHARGE_PUMP away from its reset value, so without it "HP amp" cannot power up. Unplugging and replugging the jack is the only way to recover. Do the detect at the end of the component probe when the driver owns a hp-detect GPIO and the codec's own jack detect is unused, which is the case that has no other trigger. A machine driver calling rt5645_set_jack_detect() later just repeats it. Signed-off-by: Rudi Heitbaum Link: https://patch.msgid.link/anNU3tOUR7rOReSB@5e001e58230e Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6436411203d8c702ffc055700f1a6bde488ff681 Author: Jia Jia Date: Fri Jul 24 14:09:19 2026 +0800 vhost-scsi: flush backend after device ioctls [ Upstream commit 22598f55a4c2b510b3df5e69e563387a963222ae ] vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns. Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260724060919.1569170-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit 9d682e4ea2a7479744d8de206bcade127fd17214 Author: Robert Abrahamse Date: Tue Jul 28 16:03:14 2026 +0200 ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision) [ Upstream commit cee046679655b4822f76efc9658f19efee9ac979 ] Add USB mixer mapping quirk for later revisions of the Corsair Virtuoso headset with USB IDs 0x1b1c:0x0a43 (wired) and 0x1b1c:0x0a44 (wireless). These devices exhibit the same mixer label collision as earlier Virtuoso variants: all controls are labelled "Headset", causing applications like PulseAudio to move the sidetone control instead of the main playback volume. Signed-off-by: Robert Abrahamse Link: https://patch.msgid.link/20260728140314.11601-1-denobyte2@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fb40eda15122f6b780228639c1ead6820340ff54 Author: Jiale Yao Date: Wed Jul 22 17:26:14 2026 +0800 Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame [ Upstream commit b230e5bf501c5edaf2eb0991cb862ac142031d4b ] rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c ("Bluetooth: RFCOMM: validate skb length in MCC handlers") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS). Signed-off-by: Jiale Yao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 269498ce6c1e2132b072aa0c8660404926008f03 Author: Deepanshu Kartikey Date: Sat Jul 25 19:50:28 2026 +0530 wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() [ Upstream commit a2f5286ca4f304d3fd469f01b96b518608912a5c ] The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. Reported-by: syzbot+cc867e537e4bd36f69bb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cc867e537e4bd36f69bb Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260725142028.32560-1-kartikey406@gmail.com [drop unnecessary ie_len check, update commit message] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit eeac976b74b4f697cfc517187b7cbfd72652dbbc Author: Li Qiang Date: Sun Jul 19 00:22:27 2026 +0800 cifs: validate idmap key payload length [ Upstream commit 455488cd5054bcc59db40fa1cc2c004031a5b2a5 ] The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads. Signed-off-by: Li Qiang Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0e47a180a24cea1a3036de339dd507bd33248219 Author: Vaibhav Jain Date: Wed Jul 8 07:28:00 2026 +0530 powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during crash [ Upstream commit 810d07fb4cf7577847f85a6fd6273b69cad8d580 ] Currently pseries_kexec_cpu_down() skips unregistering vpa, slb_shadow and dtl areas during a crash and kexec shutdown path. It was done to avoid doing an HCALL while crashing. However recently Anushree reported that during kernel crash while the kdump kernel was coming up, Hypervisor reported invalid values for 'vpa.yield_count' while it dispatching L2-KVM Guest vcpus. The error manifested as debug build Hypervisor assert triggering to indicate possible VPA corruption. Looking at the kexec cpu offline path it was discovered that during crash kernel doesn't unregister the VPA/SLB-Shadow/DTL area with Hypervisor. Instead it re-allocates and re-registers these areas for cpus during boot. During kexec boot the previously allocated areas can get overwritten with new content without hypervisor knowledge. This creates a small window where while kexec kernel boots and the L2-VCPUs are being dispatched, Hypervisor may try to read/write to a wrong memory area which previously belonged to older VPA. Fix this possible race and memory corruption by updating pseries_kexec_cpu_down() to also unregister vpa,slb_shadow & dtl areas during a kernel crash. Signed-off-by: Vaibhav Jain Tested-by: Anushree Mathur Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260708015802.274271-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit f4fc4f843dae4b9d4ee771dd47fb79fe92e6ad84 Author: Michal Swiatkowski Date: Fri Jul 17 11:53:25 2026 -0700 ice: pass the return value of skb_checksum_help() [ Upstream commit 2d19302f628853742c4828381abbd668c1315598 ] skb_checksum_help() can fail. Pass its return value back to the caller. Commonize this software path in goto. Instead of just returning error try calculating software checksum first. There is a check for TSO in checksum_sw_fb. Reviewed-by: Aleksandr Loktionov Signed-off-by: Michal Swiatkowski Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 298ec0c2ce644b805259a35b64ff86e58485533e Author: Madhavender Singh Date: Thu Jul 23 16:17:36 2026 +0530 ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx [ Upstream commit bf4fc9f33ec21595143132a3e7fb8b5d2c2261cd ] This laptop with an ALC236 codec requires the ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup for its mute LED to function correctly. Add the subsystem ID 0x103c:0x86c8 to the quirk table to apply this fixup. Signed-off-by: Madhavender Singh Link: https://patch.msgid.link/20260723104736.23386-1-madhav@disroot.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1fd03634e984adb5959de6b311deb9e9efa0e3a1 Author: Minhong He Date: Tue Jul 21 17:39:56 2026 +0800 phonet: check register_netdevice_notifier() error in phonet_device_init() [ Upstream commit d1ff66b66151c14b084e88040512a064b1c1e493 ] phonet_device_init() registers a netdevice notifier before calling phonet_netlink_register(), but does not check whether notifier registration succeeded. On failure, netlink setup still proceeds and init may return success without the notifier in place. Also, the existing phonet_netlink_register() failure path called phonet_device_exit(), which runs rtnl_unregister_all() even though rtnl_register_many() already unwound any partial registration. Calling the full exit helper on a partial init is not correct. Check each registration error, including proc_create_net(), and unwind only the steps that have succeeded so far, in reverse order. Signed-off-by: Minhong He Link: https://patch.msgid.link/20260721093956.162617-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09a950950e7e4e74e021e60941c8e816ef1b4f71 Author: Pengpeng Hou Date: Thu Jun 25 08:32:40 2026 +0800 drm/gma500: return errors from Oaktrail HDMI I2C reads [ Upstream commit 9b5ce5c496efd20c1c662cedba88465d39ec1f93 ] xfer_read() waits for the HDMI I2C transaction to reach I2C_TRANSACTION_DONE, but it ignores both timeout and signal returns from wait_for_completion_interruptible_timeout(). If the interrupt never advances the transaction state, the loop can wait forever. Return -ETIMEDOUT when the completion wait expires, propagate interrupted waits, and make the I2C master_xfer callback return the first transfer error instead of reporting a successful message count. Signed-off-by: Pengpeng Hou Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260625003240.6923-1-pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit 3a96bb65b4b820d8b41fa155781ec1c29e3479d4 Author: Ibrahim Hashimov Date: Tue Jul 21 13:53:46 2026 +0200 wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO [ Upstream commit 3dc723ac78a6e4fa0fd49e27e487ed319da40a9f ] hwsim_tx_info_frame_received_nl() casts the HWSIM_ATTR_TX_INFO payload to a struct hwsim_tx_rate * and unconditionally reads IEEE80211_TX_MAX_RATES entries (8 bytes) from it. The policy only bounds the attribute from above (NLA_BINARY .len is a maximum) and the op sets GENL_DONT_VALIDATE_STRICT, so a short or zero-length attribute is accepted and the loop reads past the payload. Require the exact length in the policy, so a malformed attribute is rejected before the handler runs. Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Link: https://patch.msgid.link/20260721115346.17236-1-security@auditcode.ai Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit de2b78e7e0f01362768064546aac0947cfb28b73 Author: Georgi Valkov Date: Thu Jul 16 03:17:28 2026 +0300 wifi: mwifiex: replace one-element arrays with flexible array members [ Upstream commit 1cb5845a58d8e1f85d5766c6fbcbfddf96c212a1 ] Replace deprecated one-element arrays with flexible array members. CONFIG_FORTIFY_SOURCE reports the following warning when one-element arrays are used as variable-length buffers: sta_cmd.c:1033 mwifiex_sta_prepare_cmd memcpy: detected field-spanning write (size 84) of single field "domain->triplet" at .../marvell/mwifiex/sta_cmd.c:1033 (size 3) Convert affected structs to use flexible array members. - Preserve existing wire layouts. - Use DECLARE_FLEX_ARRAY() for structs inside affected unions. Tested-on: WRT3200ACM, OpenWrt Signed-off-by: Georgi Valkov Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260716001728.57799-1-gvalkov@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 61da42fdd21d98ccb8f1ec5224659f3d09202cf4 Author: Emmanuel Grumbach Date: Fri Jul 17 17:33:36 2026 +0300 wifi: iwlwifi: bound aligned TLV advance in FW parser [ Upstream commit acad742714bdc70e7fd7f234323807c596828213 ] Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717173215.393c286488f9.Ia39144dc3ca334325ee4eacb7420901e2446fc23@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 2c08ae91df3cf11d517dc1273195f7b1df2a0ddb Author: Timur Kristóf Date: Sun Jul 12 19:39:26 2026 +0200 drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized [ Upstream commit f8922d5a946699fc2bdc7660e6778bd6726bf8b8 ] When DPM is turned off with the amdgpu.dpm=0 module parameter, the thermal work queue isn't initialized so we shouldn't schedule any work on it. Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit bd018d36171a695952c6d391471c279c9e05c8b2) Signed-off-by: Sasha Levin commit bb0fe9121aa0824211aafa33c7d0151fd25ddb75 Author: Pu Hu Date: Fri Jul 10 06:32:55 2026 +0000 arm64: kprobes: Allow reentering kprobes while single-stepping [ Upstream commit 23f851ac0078a908bf3422d6467ebc1db5828c46 ] A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This can happen when tracing or perf code runs from the debug exception path while the first kprobe is preparing or executing its out-of-line single-step instruction. Currently arm64 treats a kprobe hit in KPROBE_HIT_SS as unrecoverable, the same as a hit in KPROBE_REENTER. This is too strict. A hit in KPROBE_HIT_SS is still a one-level reentry and can be handled by saving the current kprobe state and setting up single-step for the new probe, just like reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE. The truly unrecoverable case is hitting another kprobe while already in KPROBE_REENTER, because the reentry save area has already been consumed. Move KPROBE_HIT_SS to the recoverable reentry cases and leave KPROBE_REENTER as the unrecoverable nested reentry case. This change also requires saving saved_irqflag in struct prev_kprobe. When a nested kprobe calls kprobes_save_local_irqflag(), it overwrites kcb->saved_irqflag with the currently masked DAIF value, losing the outer kprobe's original DAIF state. Without this fix, when the outer kprobe's single-step finishes, kprobes_restore_local_irqflag() applies the wrong DAIF mask and leaves interrupts permanently disabled. Extend struct prev_kprobe with a saved_irqflag field and save/restore it alongside kp and status. This ensures the outer kprobe's original interrupt state is preserved across reentry. This mirrors the x86 fix in commit 6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping"). Signed-off-by: Pu Hu Signed-off-by: Hongyan Xia Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 42c81df9427a0e8b5d05d9ece9bf92ae53f20764 Author: Yu Peng Date: Wed Jul 8 10:35:14 2026 +0800 arm64: fixmap: Allow 256K early_ioremap() at any offset [ Upstream commit 21fc7ec93f8b633b60d5bddef2f1529ff6b36185 ] NR_FIX_BTMAPS is the per-slot page limit for early_ioremap(). Since __early_ioremap() maps the page-aligned physical range, a 256K request can require one extra page when the physical address is not page-aligned. Reserve one extra page per slot so the 256K mapping budget is usable regardless of the initial page offset. Link: https://lore.kernel.org/r/08fd96fa-ee3a-4904-bd11-bb08bd90436f@kylinos.cn Signed-off-by: Yu Peng Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0f840db042caee9d2f3dcdcf97d6674f6e4c1e30 Author: Tao Cui Date: Wed Jul 15 21:24:07 2026 +0800 blk-cgroup: fix leaks and online flag on radix_tree_insert failure [ Upstream commit dbbca20764382b4d411ec2918f4e278ffe547acc ] When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy(). Acked-by: Tejun Heo Signed-off-by: Tao Cui Link: https://patch.msgid.link/20260715132407.1469777-1-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2c8c06c59ed72a42e4d32e222542b582b4911459 Author: Emmanuel Grumbach Date: Tue Jul 14 14:19:51 2026 +0300 wifi: iwlwifi: mvm: fix an off-by-1 boundary check [ Upstream commit d77aff138c9ec6c8562f4c2c9f262d3d9c4b4cb8 ] Before looking at the 11th byte, check the length is big enough. Signed-off-by: Emmanuel Grumbach Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20260714141909.d22bf52a18d0.If0ef6612a67cca671428b06dbdeec68549e50ae6@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 29531470b1bf1e8bd2df4941fe913106edbca615 Author: Filipe Manana Date: Fri Jun 12 11:52:55 2026 +0100 btrfs: fix reloc root cleanup in merge_reloc_roots() [ Upstream commit b78fe9563e2d5ae47805f1e5dc722c91fd30e1f8 ] If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root. Link: https://sashiko.dev/#/patchset/cf84f1a217c719e25b6b69e4298dd7afd36c9427.1781194426.git.fdmanana%40suse.com Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5a247097c5f94b51ffc991b444d998ad6e85875f Author: Filipe Manana Date: Tue Jun 9 16:45:39 2026 +0100 btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() [ Upstream commit 83201804efa4a5168be754e1dfc9b2faee760cac ] If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106.694368][ T5338] kasan_report+0x117/0x150 [ 106.694384][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694399][ T5338] kasan_check_range+0x264/0x2c0 [ 106.694416][ T5338] btrfs_put_root+0x2f/0x250 [ 106.694430][ T5338] btrfs_drop_and_free_fs_root+0x160/0x210 [ 106.694447][ T5338] btrfs_free_fs_roots+0x2f9/0x3c0 [ 106.694464][ T5338] ? __pfx_btrfs_free_fs_roots+0x10/0x10 [ 106.694479][ T5338] ? free_root_pointers+0x5bf/0x5f0 [ 106.694494][ T5338] close_ctree+0x798/0x12d0 [ 106.694511][ T5338] ? __pfx_close_ctree+0x10/0x10 [ 106.694526][ T5338] ? _raw_spin_unlock_irqrestore+0x74/0x80 [ 106.694599][ T5338] ? rcu_preempt_deferred_qs_irqrestore+0x906/0xbc0 [ 106.694620][ T5338] ? __rcu_read_unlock+0x83/0xe0 [ 106.694636][ T5338] ? btrfs_put_super+0x48/0x1c0 [ 106.694652][ T5338] ? __pfx_btrfs_put_super+0x10/0x10 [ 106.694667][ T5338] generic_shutdown_super+0x13d/0x2d0 [ 106.694682][ T5338] kill_anon_super+0x3b/0x70 [ 106.694695][ T5338] btrfs_kill_super+0x41/0x50 [ 106.694710][ T5338] deactivate_locked_super+0xbc/0x130 [ 106.694722][ T5338] cleanup_mnt+0x437/0x4d0 [ 106.694736][ T5338] ? _raw_spin_unlock_irq+0x23/0x50 [ 106.694752][ T5338] task_work_run+0x1d9/0x270 [ 106.694769][ T5338] ? __pfx_task_work_run+0x10/0x10 [ 106.694784][ T5338] ? do_raw_spin_unlock+0x4d/0x210 [ 106.694802][ T5338] do_exit+0x70f/0x22c0 [ 106.694817][ T5338] ? trace_irq_disable+0x3b/0x140 [ 106.694835][ T5338] ? __pfx_do_exit+0x10/0x10 [ 106.694848][ T5338] ? preempt_schedule_thunk+0x16/0x30 [ 106.694863][ T5338] ? preempt_schedule_common+0x82/0xd0 [ 106.694878][ T5338] ? preempt_schedule_thunk+0x16/0x30 [ 106.694892][ T5338] do_group_exit+0x21b/0x2d0 [ 106.694906][ T5338] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 106.694918][ T5338] __x64_sys_exit_group+0x3f/0x40 [ 106.694932][ T5338] x64_sys_call+0x221a/0x2240 [ 106.694944][ T5338] do_syscall_64+0x174/0x580 [ 106.694954][ T5338] ? clear_bhb_loop+0x40/0x90 [ 106.694967][ T5338] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 106.694978][ T5338] RIP: 0033:0x7f958ef9ce59 [ 106.694988][ T5338] Code: Unable to access opcode bytes at 0x7f958ef9ce2f. [ 106.694994][ T5338] RSP: 002b:00007fffd4058318 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 106.695008][ T5338] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f958ef9ce59 [ 106.695015][ T5338] RDX: 00007f958c3f8000 RSI: 0000000000000000 RDI: 0000000000000000 [ 106.695022][ T5338] RBP: 0000000000000003 R08: 0000000000000000 R09: 00007f958f1e73e0 [ 106.695028][ T5338] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 106.695034][ T5338] R13: 00007f958f1e73e0 R14: 0000000000000003 R15: 00007fffd40583d0 [ 106.695046][ T5338] [ 106.695050][ T5338] [ 106.821635][ T5338] Allocated by task 1061: [ 106.823446][ T5338] kasan_save_track+0x3e/0x80 [ 106.825498][ T5338] __kasan_kmalloc+0x93/0xb0 [ 106.827381][ T5338] __kmalloc_cache_noprof+0x31c/0x660 [ 106.829525][ T5338] btrfs_alloc_root+0x75/0x930 [ 106.831458][ T5338] read_tree_root_path+0x127/0xb00 [ 106.833556][ T5338] btrfs_read_tree_root+0x34/0x60 [ 106.835553][ T5338] create_reloc_root+0x6b3/0xcb0 [ 106.837556][ T5338] btrfs_init_reloc_root+0x2ec/0x4b0 [ 106.839557][ T5338] record_root_in_trans+0x2ab/0x350 [ 106.841685][ T5338] btrfs_record_root_in_trans+0x15c/0x180 [ 106.844237][ T5338] start_transaction+0x39c/0x1820 [ 106.846638][ T5338] btrfs_finish_one_ordered+0x88e/0x2680 [ 106.849436][ T5338] btrfs_work_helper+0x37b/0xc20 [ 106.851549][ T5338] process_scheduled_works+0xb5d/0x1860 [ 106.853807][ T5338] worker_thread+0xa53/0xfc0 [ 106.855773][ T5338] kthread+0x389/0x470 [ 106.857548][ T5338] ret_from_fork+0x514/0xb70 [ 106.859493][ T5338] ret_from_fork_asm+0x1a/0x30 [ 106.861504][ T5338] [ 106.862527][ T5338] Freed by task 5339: [ 106.864224][ T5338] kasan_save_track+0x3e/0x80 [ 106.866180][ T5338] kasan_save_free_info+0x46/0x50 [ 106.868371][ T5338] __kasan_slab_free+0x5c/0x80 [ 106.870462][ T5338] kfree+0x1c5/0x640 [ 106.872180][ T5338] __del_reloc_root+0x341/0x3b0 [ 106.874290][ T5338] free_reloc_roots+0x5f/0x90 [ 106.876282][ T5338] merge_reloc_roots+0x73f/0x8a0 [ 106.878489][ T5338] relocate_block_group+0xbcc/0xe70 [ 106.880742][ T5338] do_nonremap_reloc+0xa8/0x5b0 [ 106.882885][ T5338] btrfs_relocate_block_group+0x7e6/0xc40 [ 106.885336][ T5338] btrfs_relocate_chunk+0x115/0x820 [ 106.887502][ T5338] __btrfs_balance+0x1db0/0x2ae0 [ 106.889543][ T5338] btrfs_balance+0xaf3/0x11b0 [ 106.891456][ T5338] btrfs_ioctl_balance+0x3d3/0x610 [ 106.893672][ T5338] __se_sys_ioctl+0xfc/0x170 [ 106.895530][ T5338] do_syscall_64+0x174/0x580 [ 106.897518][ T5338] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 106.900101][ T5338] [ 106.901123][ T5338] The buggy address belongs to the object at ffff88803f978000 [ 106.901123][ T5338] which belongs to the cache kmalloc-4k of size 4096 [ 106.906907][ T5338] The buggy address is located 1584 bytes inside of [ 106.906907][ T5338] freed 4096-byte region [ffff88803f978000, ffff88803f979000) [ 106.912980][ T5338] [ 106.914022][ T5338] The buggy address belongs to the physical page: [ 106.916716][ T5338] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3f978 [ 106.920390][ T5338] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 106.923834][ T5338] flags: 0x4fff00000000040(head|node=1|zone=1|lastcpupid=0x7ff) [ 106.927104][ T5338] page_type: f5(slab) [ 106.928898][ T5338] raw: 04fff00000000040 ffff88801ac42140 dead000000000122 0000000000000000 [ 106.932507][ T5338] raw: 0000000000000000 0000000800040004 00000000f5000000 0000000000000000 [ 106.936193][ T5338] head: 04fff00000000040 ffff88801ac42140 dead000000000122 0000000000000000 [ 106.939856][ T5338] head: 0000000000000000 0000000800040004 00000000f5000000 0000000000000000 [ 106.943601][ T5338] head: 04fff00000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff [ 106.947268][ T5338] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 [ 106.950988][ T5338] page dumped because: kasan: bad access detected [ 106.953710][ T5338] page_owner tracks the page as allocated [ 106.956198][ T5338] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 24, tgid 24 (kworker/u4:2), ts 105728970387, free_ts 29540875453 [ 106.964984][ T5338] post_alloc_hook+0x22d/0x280 [ 106.966956][ T5338] get_page_from_freelist+0x2593/0x2610 [ 106.969307][ T5338] __alloc_frozen_pages_noprof+0x18d/0x380 [ 106.971839][ T5338] allocate_slab+0x77/0x660 [ 106.973709][ T5338] refill_objects+0x339/0x3d0 [ 106.975696][ T5338] __pcs_replace_empty_main+0x321/0x720 [ 106.978136][ T5338] __kmalloc_node_track_caller_noprof+0x572/0x7b0 [ 106.981009][ T5338] __alloc_skb+0x2c1/0x7d0 [ 106.982983][ T5338] nsim_dev_trap_report_work+0x29a/0xb90 [ 106.985356][ T5338] process_scheduled_works+0xb5d/0x1860 [ 106.987710][ T5338] worker_thread+0xa53/0xfc0 [ 106.989847][ T5338] kthread+0x389/0x470 [ 106.991727][ T5338] ret_from_fork+0x514/0xb70 [ 106.993722][ T5338] ret_from_fork_asm+0x1a/0x30 [ 106.995900][ T5338] page last free pid 77 tgid 77 stack trace: [ 106.998479][ T5338] __free_frozen_pages+0xc1c/0xd30 [ 107.000819][ T5338] vfree+0x1d1/0x2f0 [ 107.002631][ T5338] delayed_vfree_work+0x55/0x80 [ 107.004848][ T5338] process_scheduled_works+0xb5d/0x1860 [ 107.007366][ T5338] worker_thread+0xa53/0xfc0 [ 107.009388][ T5338] kthread+0x389/0x470 [ 107.011177][ T5338] ret_from_fork+0x514/0xb70 [ 107.013313][ T5338] ret_from_fork_asm+0x1a/0x30 [ 107.015454][ T5338] [ 107.016460][ T5338] Memory state around the buggy address: [ 107.019052][ T5338] ffff88803f978500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.022691][ T5338] ffff88803f978580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.026264][ T5338] >ffff88803f978600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.029721][ T5338] ^ [ 107.032062][ T5338] ffff88803f978680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.035547][ T5338] ffff88803f978700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.038865][ T5338] ================================================================== Fix this by resetting a root's ->reloc_root if we get an error while trying to merge a reloc root. Reported-by: syzbot+b3d472d13f9d7bf20669@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/6a1ebde9.c1435f33.112120.0176.GAE@google.com/ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 795ba65f46fe44061f1195951c122cc8ec685d44 Author: Pengpeng Hou Date: Sun Jul 5 16:48:24 2026 +0800 wifi: rsi: validate beacon length before fixed buffer copy [ Upstream commit 8ecdeb8b8a33b22c597299043c0dcfce50beb9ea ] rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260705084824.68105-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 67bd3d2350d17c2f4fb158c3f917c10b15ecbc94 Author: Jozsef Kadlecsik Date: Thu Jul 2 15:46:57 2026 +0200 netfilter: ipset: mark the rcu locked areas properly [ Upstream commit 5d0c22e73656d050daffad10a2ba8765ce8441c8 ] When we bump the uref counter, there's no need to keep the rcu lock because the referred hash table can't disappear. Also, from the same reason in mtype_gc we need the rcu lock and not a spinlock. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bb18262c19feb690ddde58c70e3ad04bc6fe566e Author: Pengpeng Hou Date: Sun Jul 5 16:35:19 2026 +0800 wifi: libipw: fix key index receive bound checks [ Upstream commit 74ed3669f26803b1761c1f55403062bea44c3466 ] libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260705083519.23567-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f4730065b535a13b34a9ef80bacdc0bb14e49819 Author: Liang Hao Date: Sun Jul 5 15:47:59 2026 +0800 gpio: dwapb: Mask interrupts at hardware initialization [ Upstream commit aaf7766ba3b99a3834319e7cf939838afc705574 ] GPIO interrupts may retain stale state across warm reboots when peripherals remain powered. If a GPIO line is not explicitly configured for interrupts, this can result in interrupt storms due to missing handlers. Fix this by ensuring all interrupts are masked and disabled at hardware initialization time via the init_hw() callback. Pending interrupts are also cleared to start from a known-safe state. Interrupts will be unmasked only when explicitly configured by userspace or kernel drivers. Signed-off-by: Liang Hao Link: https://patch.msgid.link/20260705074759.47863-1-haohlliang@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 68c92c991ddb75dfd3fd62a94a1d4d2dde44dc3c Author: Pengpeng Hou Date: Sat Jul 4 09:11:40 2026 +0800 wifi: libertas: reject short monitor TX frames [ Upstream commit 13ff543e0b2c713aedeaadadde686686e949dc78 ] In monitor mode, lbs_hard_start_xmit() casts skb->data to a radiotap TX header, skips that header, and then copies the 802.11 destination address from offset 4 in the remaining frame. The generic length check only rejects zero-length and oversized skbs, so a short monitor frame can be read past the end of the skb data. Require enough bytes for the radiotap TX header and the destination address field before using the monitor-mode header layout. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704011140.37639-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6937b06d55b528e961feff8cc083b97ede622e02 Author: Pengpeng Hou Date: Wed Jul 1 13:34:14 2026 +0800 wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers [ Upstream commit 843fe9bc583b7686ca68312ac9319c9240a73c03 ] rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260701053414.34015-1-pengpeng@iscas.ac.cn [drop useless length check] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 51092dc769f021e9634474e1bd5a561da477fbdb Author: Zhao Li Date: Sat Jun 13 02:50:45 2026 +0800 wifi: mac80211: validate deauth frame length before reason access [ Upstream commit 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f ] ieee80211_rx_mgmt_deauth() reads the deauth reason code before checking that the fixed field is actually present in the received frame. Validate the deauth frame length first and only then read the reason code. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612185042.66260-6-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 75bb29239c44ce94bc66ad0ac0d28c6ddddce078 Author: Corentin Labbe Date: Fri Jul 3 13:49:32 2026 +0000 wifi: ralink: RT2X00: init EEPROM properly [ Upstream commit 0a2581cbae9e442835f68d22044157db61cdf54d ] I have an hostapd setup with a 01:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe The setup work fine on 6.18.26-gentoo It breaks on 6.18.33-gentoo (and still broken on 6.18.37) I found an hint in dmesg: On 6.18.26-gentoo I see: May 31 15:48:45 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0003 detected On 6.18.33-gentoo I see: May 31 15:22:57 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0006 detected The RF chipset seems badly detected. The problem was the EEPROM which was badly initialized. Probably the origin was in some PCI change but unfortunately I couldn't play to bisect/reboot often the board with this card to do it. Signed-off-by: Corentin Labbe Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260703134932.3786771-1-clabbe@baylibre.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 91acd231f219452fa58285239f83945accad9513 Author: Pengpeng Hou Date: Sun Jul 5 16:46:01 2026 +0800 ALSA: usb-audio: caiaq: validate EP1 reply lengths [ Upstream commit aba30af07d4fe499b50209801eba9da8a815522f ] usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260705084601.56400-1-pengpeng@iscas.ac.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e2806390aa1c4d5b3f7a68f10a56ae12c71c00d8 Author: Yousef Alhouseen Date: Sat Jun 27 00:38:05 2026 +0200 xen/gntalloc: validate grant count before allocation [ Upstream commit 2299822f3f466b5dcad2377bf63986199f881a6b ] gntalloc_ioctl_alloc() allocates the grant-id array before checking whether the requested count fits within the global grant limit. Counts above that limit cannot succeed, so reject them before the user-controlled allocation reaches kcalloc(). Use a subtraction-based check while holding gref_mutex so adding the requested count cannot wrap. Also cast the count before advancing the per-file index so the page-size multiplication is performed in 64-bit arithmetic. Signed-off-by: Yousef Alhouseen Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com> Signed-off-by: Sasha Levin commit fe40a19d571cbb584eea46038ee919d8712b2d2c Author: Farhad Alemi Date: Mon Jun 1 20:10:08 2026 -0700 freevxfs: don't BUG() on unknown typed-extent type [ Upstream commit 704d48d81dc41470e108811c32c577ada66192d4 ] vxfs_bmap_typed() handles four typed-extent types and calls BUG() in its default case, so an on-disk typed extent with any other type value crashes the kernel. It is reachable from ioctl(FIBMAP) on a regular file: kernel BUG at fs/freevxfs/vxfs_bmap.c:230! RIP: vxfs_bmap_typed fs/freevxfs/vxfs_bmap.c:230 [inline] vxfs_bmap1+0x128a/0x12d0 fs/freevxfs/vxfs_bmap.c:257 Replace the BUG() with WARN_ON_ONCE() and return 0 -- the value vxfs_bmap_typed() already returns on failure (and from the DEV4 case above); vxfs_getblk() maps 0 to -EIO, so the ioctl fails cleanly. Reported-by: Farhad Alemi Signed-off-by: Farhad Alemi Link: https://patch.msgid.link/CA+0ovChveuAwv=t15dr2m09E32bM48hHJxvfeEYZOhdNiEc9Tw@mail.gmail.com Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9cde9af9735b9c3e16339e9128bc9a483599c1b3 Author: Yousef Alhouseen Date: Mon Jun 29 18:05:17 2026 +0200 xen/front-pgdir-shbuf: free grant reference head on errors [ Upstream commit 678d59219ce0ae883f04c96936222c6168ef1164 ] grant_references() allocates a private grant-reference head before claiming references for the page directory and, for guest-owned buffers, the data pages. The success path frees the remaining head, but claim failures and grant_refs_for_buffer() errors return immediately. Unwind through a common exit path so the private grant-reference head is released even when granting fails part-way through setup. The caller still tears down any references already stored in buf->grefs. Signed-off-by: Yousef Alhouseen Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Message-ID: <20260629160517.29340-1-alhouseenyousef@gmail.com> Signed-off-by: Sasha Levin commit ca06df1c921e7b7792df69fe36dcb6c5855badb0 Author: Gustavo Kenji Mendonça Kaneko Date: Tue Jun 9 13:08:33 2026 +0000 drm/arm/komeda: fix error handling for clk_prepare_enable() and callers [ Upstream commit 6502eb8cfcd6f7bc5f1f8b73ee524112bd93319d ] komeda_dev_resume() calls clk_prepare_enable() without checking the return value. If the clock fails to enable, the function returns 0 (success) while IRQs are enabled and IOMMU is connected on potentially unclocked hardware, causing undefined behavior on resume. Propagate the error from clk_prepare_enable() and fix all call sites in komeda_drv.c that previously ignored the return value of komeda_dev_resume(): - komeda_platform_probe(): if resume fails, jump to err_destroy_mdev (skipping the suspend call, since the clock was never enabled) - komeda_pm_resume(): propagate the error and skip drm_mode_config_helper_resume() on failure This issue was found by code review without access to Komeda hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260609130828.1066038-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 39cb6ff947c16a576ea68c5f272e634acdcb0085 Author: Florian Westphal Date: Wed Jun 24 23:06:43 2026 +0200 netfilter: nf_conntrack_expect: zero at allocation time [ Upstream commit 241ccd2fed9051db443aadce248fc0ab30f55e97 ] There are occasional LLM hints wrt. leaking uninitialized data to userspace via ctnetlink. Just zero at allocation time, expectations are not frequently used these days. Intentionally keeps _init as-is because we could theoretically support re-init, so add the missing exp->dir there. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 155049da659f3ff6124bff5f8234372fc2b1a93b Author: Gustavo Kenji Mendonça Kaneko Date: Tue Jun 9 13:08:19 2026 +0000 drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend [ Upstream commit 46f715a16989f4e7bbbc2eb41447051874b027f3 ] malidp_runtime_pm_resume() calls clk_prepare_enable() three times without checking the return value. If any clock fails to enable, the driver silently proceeds with unclocked hardware, leading to undefined behavior. Convert both the resume and suspend paths to use the clk_bulk API: clk_bulk_prepare_enable() in resume checks the return value and rolls back any successfully enabled clocks on failure; clk_bulk_disable_unprepare() in suspend keeps the two paths symmetric. This issue was found by code review without access to Mali DP hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260609130812.1065699-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 770e957d3ec42bd98d10d85bd05700e129bed874 Author: Haoxiang Li Date: Sun Jun 21 15:19:35 2026 +0800 fbdev: pm2fb: unwind WC setup on probe failure [ Upstream commit 16eb19f0c90af03bda6ba66586d7bb0e9cf85b43 ] Add arch_phys_wc_del() on error path to keep the write-combining setup balanced when later probe steps fail. Signed-off-by: Haoxiang Li Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit d2fb6f47be78f4fe3a83643b6abcbba649bba8dd Author: Adriana Stancu Date: Thu Apr 16 07:21:51 2026 -0700 rtc: bq32000: add delay between RTC reads [ Upstream commit d4992b7050a10079bc760bdc5b8688e05a09dfc2 ] When the RTC is used on systems without a interrupt line, userspace tools like `hwclock` fall back to a frequent polling loop to synchronize with the edge of the next second. On the BQ32000, this aggressive polling can temporarly lock the register refresh cycle, because the continuous transfers prevent the hardware from updating the buffer. This results in stale data reads or select() timeouts in userspace. This patch introduces a delay before reading the RTC registers in order to provide a sufficient idle time for the hardware to sync with the register buffer. Signed-off-by: Adriana Stancu Link: https://patch.msgid.link/20260416142151.3385827-1-adriana@arista.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit f86bca5b7857b85bfa8afdb4fa895d7c0a3f7ebc Author: Runyu Xiao Date: Fri Jun 19 23:18:16 2026 +0800 net: au1000: move free_irq out of the close-time spinlocked section [ Upstream commit f48763beab4eea41fc480c9702ec6eebe8d75e4f ] au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported "BUG: sleeping function called from invalid context" and "Invalid wait context" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section. Signed-off-by: Runyu Xiao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260619151816.1144289-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4ace8aed2228d73eb6d0e360aa85d643c87b5407 Author: Krzysztof Wilczyński Date: Fri Jun 12 18:24:48 2026 +0000 PCI/sysfs: Use kstrtobool() to parse the ROM attribute input [ Upstream commit 92742802ecbf215a2b60dcfd326d2213595010f1 ] pci_write_rom() controls access to the ROM content through the corresponding sysfs attribute, and treats the input as a request to disable only when it matches the string "0\n" exactly: if ((off == 0) && (*buf == '0') && (count == 2)) The count == 2 condition encodes the trailing newline that echo(1) appends. This was found when userspace wrote "0" without a trailing newline aiming to disable access, which failed to match the condition above and enabled access instead. For example: $ echo 0 > rom # "0\n", count 2, access disabled $ echo -n 0 > rom # "0", count 1, access enabled $ echo > rom # "", count 1, access enabled (likely not desirable) Parse the input with kstrtobool(), which handles common boolean inputs such as "0", "1", "n", "y" or "off", "on", with or without a trailing newline, so both of the above disable access, and update the now stale comment. As a side effect, input that does not parse as a boolean is rejected with -EINVAL rather than enabling access. The documented "0" and "1" continue to work as before, and rejecting malformed input brings the attribute in line with how sysfs attributes typically handle it. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260612182448.552406-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 4b0ddbf08307cbb682ec7ff65fee7063a99f2cbb Author: Tommy Huang Date: Mon Jun 1 17:14:07 2026 +0800 rtc: aspeed: add AST2700 compatible [ Upstream commit 3319cfeeb8c4047026f84df045c438f7bbd338a6 ] Add support for matching the RTC controller on ASPEED AST2700 SoCs. The AST2700 RTC controller is compatible with the existing ASPEED RTC driver implementation. Signed-off-by: Tommy Huang Link: https://patch.msgid.link/20260601-ast2700-rtc-v1-2-15d4ca46500a@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6b5552449fc5acb8e6ecf045b46702b29b71165a Author: Samuel Moelius Date: Wed Jun 3 15:11:40 2026 +0000 f2fs: validate inline dentry name lengths before conversion [ Upstream commit cfcd0e49a178b3dac2c0ece656079081dbf5da74 ] Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 647c7289a3960118e249c0a53da6f1ebba1e47a3 Author: Chen Cheng Date: Thu Jun 18 10:57:35 2026 +0800 md/raid5: let stripe batch bm_seq comparison wrap-safe [ Upstream commit 00e93faf4cea9e8802ac5dfee0952d84fc95c40f ] Once the 32-bit seq wraps, a newer bm_seq can look smaller than old, so .. covert to wrap-safe calculate way. Signed-off-by: Chen Cheng Link: https://patch.msgid.link/20260618025735.915113-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit d54417acb22d9e8bc404a8598330bc9729ee7146 Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:19 2026 +0800 PCI: mediatek: Protect root bus removal with rescan lock [ Upstream commit a29812a55da8d0dbeb071b26ac428c338e3fc389 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-7-18255117159@163.com Signed-off-by: Sasha Levin commit 025308e7c9cd10112b73558c9f63f8f7285fa726 Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:20 2026 +0800 PCI: rockchip: Protect root bus removal with rescan lock [ Upstream commit 0bd9611587bb494c33566d825fe34b2705e4b167 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-8-18255117159@163.com Signed-off-by: Sasha Levin commit cf9d84d1b6a7c3f3780c043df220a7e9e38137eb Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:16 2026 +0800 PCI: altera: Protect root bus removal with rescan lock [ Upstream commit a8759c8ac48c0419f5899e95a6ffc611b07c965b ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-4-18255117159@163.com Signed-off-by: Sasha Levin commit e7d9d7be2c1f8d434032983bc86a05805178c9c9 Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:18 2026 +0800 PCI: iproc: Protect root bus removal with rescan lock [ Upstream commit a6a64e150f12ad5391e0a0d60f6a3d119b06ce50 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-6-18255117159@163.com Signed-off-by: Sasha Levin commit c69c9abf06b4d23c3ba41e629b8081e156e543a6 Author: Jean-Louis Colaco Date: Thu Jun 18 13:32:02 2026 +0200 ALSA: usb-audio: Add quirk for YAMAHA CDS3000 [ Upstream commit 348f69320e4db6ebec6940c81154bec4b9eb275a ] This quirk is identical to the one for the Yamaha Steinberg UR22, here applied to a CD player that also uses the Steinberg USB interface. This quirk is necessary to avoid sporadic "clic" noise when using the DAC of the player. Signed-off-by: Jean-Louis Colaco Link: https://patch.msgid.link/20260618113202.8363-1-jean-louis.colaco@orange.fr Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1581a6c1f054a9a93c32e947fdca3df7a05e3747 Author: Tobias Deiminger Date: Tue Mar 31 22:28:48 2026 +0200 leds: pca9532: Don't stop blinking for non-zero brightness [ Upstream commit 0261683a4d31783d680e74b3ae5f22f6a62128cc ] pca9532 unexpectedly stopped blinking when changing brightness to a non-zero value. To reproduce: echo timer > /sys/class/leds/led-1/trigger # blinks echo 255 > /sys/class/leds/led-1/brightness # blinking stops, light on cat /sys/class/leds/led-1/trigger # still claims [timer] According to Documentation/leds/leds-class.rst, only brightness = 0 shall be a stop condition: > You can change the brightness value of a LED independently of the > timer trigger. However, if you set the brightness value to LED_OFF it > will also disable the timer trigger. Therefore add a guard to continue blinking when brightness != LED_OFF, similar to how pca955x does it since 575f10dc64a2 ("leds: pca955x: Add HW blink support"). Signed-off-by: Tobias Deiminger Link: https://patch.msgid.link/20260331202848.658676-1-tobias.deiminger@linutronix.de Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 698271d765f7d2282849a6aea78e0830072f59bd Author: Yousef Alhouseen Date: Thu May 21 20:12:05 2026 +0200 leds: uleds: Return -EFAULT on copy_to_user() failure [ Upstream commit 61ed78f55a46e12afd4b464c4ba736f55ff33c5e ] uleds_read() copies the current brightness value to userspace but ignores copy_to_user() failures. It then clears the pending update and reports a successful full read even when no data was copied. Return -EFAULT when the copy fails and leave the update pending so a later read can retry. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260521181205.15130-1-alhouseenyousef@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit cf47bf02f4a698eac0e19a973100bd108ac275a2 Author: Galen Hassen Date: Tue Jun 16 10:32:57 2026 -0700 ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5 16AKP10 [ Upstream commit f7c4968ae3af3e819428da5416c2dfd361473f5c ] The Lenovo IdeaPad Slim 5 16AKP10 (PCI SSID 17aa:38b6) uses the Conexant SN6140 codec. The internal microphone is on pin 0x1a but the BIOS configures it with pin default 0x95a60120, which includes a jack detection bit that causes the kernel to treat it as an unplugged external mic rather than a fixed internal mic. Add a pin config quirk that overrides pin 0x1a to 0x95a60130, setting the connectivity bits to indicate a fixed/always-connected device. This allows the internal microphone to be correctly identified and used. Signed-off-by: Galen Hassen Link: https://patch.msgid.link/20260616173257.37373-1-rwekyes@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4e3db4671f2650599039973365e0b9cd74b21b85 Author: Rob Herring (Arm) Date: Fri Jun 12 16:52:16 2026 -0500 gpio: pisosr: Read "ngpios" as u32 [ Upstream commit 4910aa198d25e5d1067236560ba34ab12bccc677 ] The generic "ngpios" property is encoded as a normal uint32 cell. The pisosr driver stores it in the gpio_chip field, but reading it with a u16 helper does not match the DT property encoding. Read "ngpios" as u32 and keep the existing assignment to the chip field. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260612215216.1887485-1-robh@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit cdc137905c25df0ea78ef05341709ba0982876c4 Author: Arnd Bergmann Date: Thu Jun 11 14:55:56 2026 +0200 scsi: bfa: Reduce kernel stack usage in bfa_fcs_lport_fdmi_build_portattr_block() [ Upstream commit 57a6ed0b41677ccc5e28cc0976e495c1dfa33747 ] bfa_fcs_fdmi_get_portattr() gets inlined into multiple places and has two fairly large variables on the stack, to the point of causing a warning in some randconfig builds: drivers/scsi/bfa/bfa_fcs_lport.c:2198:1: error: stack frame size (1560) exceeds limit (1280) in 'bfa_fcs_lport_fdmi_build_portattr_block' [-Werror,-Wframe-larger-than] 2198 | bfa_fcs_lport_fdmi_build_portattr_block(struct bfa_fcs_lport_fdmi_s *fdmi, | ^ drivers/scsi/bfa/bfa_fcs_lport.c:1856:1: error: stack frame size (1600) exceeds limit (1280) in 'bfa_fcs_lport_fdmi_build_rhba_pyld' [-Werror,-Wframe-larger-than] 1856 | bfa_fcs_lport_fdmi_build_rhba_pyld(struct bfa_fcs_lport_fdmi_s *fdmi, u8 *pyld) | ^ Mark the inner function as noinline_for_stack to keep it separate from the other variables and prevent multiple copies of the same variable to get inlined here. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260611125601.3385418-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d0304af8c9bcc04d66dd2f732caf4d0137ae124c Author: Zhang Tianci Date: Thu Dec 25 19:11:56 2025 +0800 fuse: set ff->flock only on success [ Upstream commit 71947173cef279be5eed209ec28f8c11f9d73159 ] If FUSE_SETLK fails (e.g., due to EWOULDBLOCK), we shall not set FUSE_RELEASE_FLOCK_UNLOCK in fuse_file_release(). Reported-by: Li Yichao Signed-off-by: Zhang Tianci Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 249be13398d3c2f460ca643fb67749371b5bf023 Author: Rosen Penev Date: Thu May 7 17:08:34 2026 -0700 sparc: Disable compat support with LLD [ Upstream commit 852fed2e8bfe195351fb0078ba7245d41154e7a5 ] An LLVM=1 sparc64 allmodconfig enables COMPAT and then tries to build the 32-bit vDSO. That path cannot be linked with ld.lld: ld.lld: error: unknown emulation: elf32_sparc ld.lld does not support the 32-bit SPARC ELF emulation used for the compat vDSO, so keep COMPAT disabled when LLD is the linker. This avoids selecting an unsupported build path while leaving the existing GNU ld configuration unchanged. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev Acked-by: Nathan Chancellor Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20260508000834.834824-1-rosenp@gmail.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 26bec64b4b3378fef9c415afcdb3fa244d608a4f Author: Alice Mikityanska Date: Thu Jun 11 21:29:45 2026 +0200 net/sched: act_csum: don't mangle UDP tunnel GSO packets [ Upstream commit 9bcb30b389ec5888590cb6ec58c7a3b80fe49a11 ] Similar to commit add641e7dee3 ("sched: act_csum: don't mangle TCP and UDP GSO packets"), UDP tunnel GSO packets going through act_csum shouldn't have their checksum calculated at this point, because it will be done after segmentation. Setting the checksum in act_csum modifies skb->ip_summed and prevents inner IP csum offload from kicking in, resulting in a packet with a bad checksum. Add UDP tunnel GSO packets to the exceptions, and also add UDP GSO (SKB_GSO_UDP_L4), as the same logic as in the commit mentioned above applies to UDP GSO too. Signed-off-by: Alice Mikityanska Reviewed-by: Davide Caratti Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260611192955.604661-2-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c5bc2e0cdb5ee3d0f6d1464e5c889307cbbda3ed Author: Agalakov Daniil Date: Tue Jun 9 14:35:54 2026 -0700 e1000e: limit endianness conversion to boundary words [ Upstream commit a5ecafcfb27baf2dba766c4fd99dbb947f4e85d8 ] [Why] In e1000_set_eeprom(), the eeprom_buff is allocated to hold a range of words. However, only the boundary words (the first and the last) are populated from the EEPROM if the write request is not word-aligned. The words in the middle of the buffer remain uninitialized because they are intended to be completely overwritten by the new data via memcpy(). The previous implementation had a loop that performed le16_to_cpus() on the entire buffer. This resulted in endianness conversion being performed on uninitialized memory for all interior words. Fix this by converting the endianness only for the boundary words immediately after they are successfully read from the EEPROM. Found by Linux Verification Center (linuxtesting.org) with SVACE. Co-developed-by: Iskhakov Daniil Signed-off-by: Iskhakov Daniil Signed-off-by: Agalakov Daniil Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260609213559.178657-14-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8a9fa5572e37fab452befe4a647b2ecf3bcbfe93 Author: Raf Dickson Date: Fri Jun 12 04:58:42 2026 +0000 vsock: use sk_acceptq_is_full() helper in all transports [ Upstream commit 4ff2e84ff1b33d79fa0e3ae355ce4a334908ef9a ] Replace the open-coded backlog check with sk_acceptq_is_full(). The helper uses > instead of >=, which is the correct comparison per commit 64a146513f8f ("[NET]: Revert incorrect accept queue backlog changes."), and adds READ_ONCE() for proper memory ordering. Suggested-by: Stefano Garzarella Signed-off-by: Raf Dickson Reviewed-by: Stefano Garzarella Reviewed-by: Luigi Leonardi Link: https://patch.msgid.link/20260612045842.122207-1-rafdog35@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c9d57b5dc098b84631d0b3559c84c499ea2170a Author: Nazim Amirul Date: Tue Jun 9 05:17:03 2026 -0700 net: stmmac: xgmac2: disable RBUE in default RX interrupt mask [ Upstream commit d3265c19b35d036bba327b36b5366bee76b0157c ] Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact. Reviewed-by: Maxime Chevallier Signed-off-by: Nazim Amirul Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260609121703.9736-1-muhammad.nazim.amirul.nazle.asmade@altera.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76be21b633f4956e3fb96364dd8f5913d3b24f29 Author: Rosen Penev Date: Tue May 5 20:18:15 2026 -0700 sparc64: uprobes: add missing break [ Upstream commit 5b0eee4cd812bd6547eea393cb9b5c0322f26c88 ] Missing fallthrough causes failure with newer compilers: arch/sparc/kernel/uprobes.c:284:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] 284 | default: | ^ arch/sparc/kernel/uprobes.c:284:2: note: insert 'break;' to avoid fall-through 284 | default: | ^ | break; Signed-off-by: Rosen Penev Reviewed-by: Masami Hiramatsu (Google) Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 6ea1fd70313cb651ecd937ffdf1c70922f86637d Author: bui duc phuc Date: Tue Jun 2 17:16:07 2026 +0700 ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure [ Upstream commit 3546e9aa691ac981e4734fedd1646d0180784893 ] If regcache_sync() fails during runtime resume, the driver disables the clocks and returns an error. However, the regmap cache-only mode is left disabled. Restore cache-only mode in the error path so subsequent register accesses continue to use the cache while the device is inactive. Reported-by: Sashiko AI Review Closes: https://lore.kernel.org/all/20260522103713.6C09D1F000E9@smtp.kernel.org/ Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260602101608.45137-5-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b4f9b5800304f5fd20e01cc15a1507017656df5f Author: bui duc phuc Date: Tue Jun 2 17:16:06 2026 +0700 ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence [ Upstream commit 3168721d6ec3b610edf6a3c22ad190722a27d276 ] Enable the 'hclk' bus clock before the 'clk' controller clock during runtime resume. The bus clock provides the register access interface, so enable it before the controller clock. This also makes the resume sequence the reverse of the suspend sequence, which keeps the clock ordering consistent. Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260602101608.45137-4-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 105ea8b7a29b473cbe3aa1e542997700c98e3adc Author: bui duc phuc Date: Tue Jun 2 17:16:08 2026 +0700 ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt [ Upstream commit ee7b5f7b39332febf917f9ebf212842cc9379815 ] rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses. Reported-by: Sashiko AI Review Closes: https://lore.kernel.org/all/20260522110302.349421F000E9@smtp.kernel.org/ Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260602101608.45137-6-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8104cd9859b6de0826cffa68adf2c1461185823b Author: Samuel Moelius Date: Mon Jun 8 23:57:05 2026 +0000 Bluetooth: L2CAP: validate connectionless PSM length [ Upstream commit a40a5f922546b3bd7c094d882b29177db4f2abe0 ] Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c080fc557bb42f24e0225b5ef1c56db2264f19ab Author: Potin Lai Date: Thu Jun 11 13:46:18 2026 +0800 hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i [ Upstream commit 83dda7ed185501ba1f8165aeca83ff4a8ef7c263 ] Swap the high setting and low setting coefficients in the lm25066_coeff table for LM5064, LM5066, and LM5066i. The coefficients were previously mapped incorrectly, resulting in inverted current and power scaling. Additionally, dynamically assign the exponent (R) registers inside the probe's LM25066_DEV_SETUP_CL check. This ensures that the proper exponent is applied (e.g., for LM25056, high setting power exponent is -4, but low setting power exponent is -3). Signed-off-by: Potin Lai Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b2b31193df6387e0a7a151cfba16c21664ce6b45 Author: Jose Ignacio Tornos Martinez Date: Wed Jun 3 12:58:53 2026 +0200 PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems [ Upstream commit 6a4f64c3a3ada43e71ef1e06da89beb36bdaeefa ] Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems) do not properly support Secondary Bus Reset (SBR). Testing confirms this is device-specific, not deployment-specific: MediaTek MT7925e successfully uses bus reset through the same passive M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is properly wired through the adapters. Prevent use of Secondary Bus Reset for these devices. Signed-off-by: Jose Ignacio Tornos Martinez Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/all/20260609163649.319755-4-jtornosm@redhat.com Signed-off-by: Sasha Levin commit 0e3467b655cfbc1ed495d5ae065c05c4354f76cb Author: Yuho Choi Date: Mon Jun 8 12:22:30 2026 -0400 sctp: Unwind address notifier registration on failure [ Upstream commit c8459ee2fef502d6ef6c063751c33d9ac7943eab ] sctp_v4_add_protocol() and sctp_v6_add_protocol() register their address notifiers before registering the SCTP protocol handlers. If protocol registration fails, the functions return without unregistering the notifiers. Unregister the notifiers on the protocol registration failure paths. Also propagate notifier registration failures instead of ignoring them. Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260608162230.46644-1-dbgh9129@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 768d96387a683000464491218297e9d55351a2d5 Author: Nikolay Metchev Date: Tue Jun 9 22:33:09 2026 +0100 platform/x86: intel-hid: Add HP ProBook x360 440 G1 to button_array_table [ Upstream commit c39023ca9a447f09c072080efc84d6874c2275c9 ] The volume rocker buttons on the HP ProBook x360 440 G1 convertible emit events 0xc4-0xc7 via the intel-hid ACPI device (INT33D5). These codes are only present in intel_array_keymap, which is used when the "5 button array" input device exists. On this machine button_array_present() returns false because the firmware does not advertise the array through the HEBC method, so notify_handler() routes the events to a NULL priv->array and they are dropped as "unknown event 0xc4". As a result the side volume keys do nothing. Add the machine to button_array_table so the array device is created and the volume rocker emits KEY_VOLUMEUP / KEY_VOLUMEDOWN. This is equivalent to booting with the enable_5_button_array=1 module parameter, which was used to confirm the fix on the affected hardware. Signed-off-by: Nikolay Metchev Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260609213309.445019-1-nikolaymetchev@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d79a5bd351e4ecaaa2fdc4f85423f2877ca5ef80 Author: Xu Rao Date: Wed Jun 10 13:28:35 2026 +0800 ata: libata-pmp: add JMicron JMS562 quirk [ Upstream commit c62aff1174cf88e10716c7513702443c47551fc6 ] JMicron JMS562, as used in QNAP QDA-A2AR RAID1 adapters, may keep the exported ATA device not ready while the array is rebuilding. In this state, libata may repeatedly try to softreset and classify the fan-out link. On the affected adapter, this can time out, make PMP/SCR access fail, and eventually disable the fan-out link before the RAID volume is exported. A failing boot shows the fan-out link failing SRST, PMP access timing out, SCR read failing, and the link being disabled: ata4.00: softreset failed (device not ready) ata4.15: qc timeout after 3000 msecs (cmd 0xe4) ata4.00: failed to read SCR 0 (Emask=0x4) ata4.00: failed to recover link after 3 tries, disabling After that, the root filesystem on the exported RAID volume cannot be found. Add JMS562 to the existing JMicron PMP quirk that disables LPM, avoids softreset on fan-out links, and assumes an ATA device. This prevents libata from dropping the exported RAID volume during rebuild recovery. Signed-off-by: Xu Rao Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 72b7f8594278d353c78a179bc342b23c039e6b89 Author: Kory Maincent Date: Mon Jun 8 17:23:43 2026 +0200 hwmon: (adt7462) Add of_match_table to support devicetree [ Upstream commit cd1b42617aafe01810ab7d3b9948d2f5fa9fb8af ] Add of_match_table to add support of devicetree probing. Signed-off-by: Kory Maincent [rgantois: Removed of_match_ptr().] Signed-off-by: Romain Gantois Link: https://lore.kernel.org/r/20260608-adt7462-bindings-v2-1-272982c40325@bootlin.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 247eb94e90bb420fa39c86a84907af0fd0eeee2d Author: Jiajia Liu Date: Tue Jun 2 13:43:49 2026 +0800 wifi: mt76: transform aspm_conf for pci_disable_link_state [ Upstream commit 2dd78856223484895306351df1f903a4b75d213f ] commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1) and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4). On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able to disable L1. Fix this by transforming aspm_conf to pcie link state. Signed-off-by: Jiajia Liu Link: https://patch.msgid.link/20260602054349.42429-1-liujia6264@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a781bbcbb686b5942aae9240dbe6b53475247ce7 Author: Gleb Sonichev Date: Mon May 25 13:00:47 2026 +0300 platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk table [ Upstream commit bfe91a80b13f8068f6fa07aa8c468d284150d4ad ] The Inspiron N5110 needs the touchpad LED quirk (Vostro V130 quirk) to properly control the touchpad LED. Add its DMI identifier to the existing quirk table, next to the similar Inspiron M5110 entry. Tested on Dell Inspiron N5110. The touchpad LED works correctly with this quirk enabled. Signed-off-by: Gleb Sonichev Acked-by: Pali Rohár Link: https://patch.msgid.link/20260525100047.20046-1-sonichev555@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 9c1c814a662d9c81959eba591bb52b24639390f2 Author: Rosen Penev Date: Wed Jun 3 16:08:21 2026 -0700 net: ibm: emac: mal: fix potential system hang in mal_remove() [ Upstream commit 7c5d41f87f079990bf241359e3c1332d8d10fe87 ] napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled). Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260603230821.5619-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de09551abe246b632412a773170ce3bee305ff49 Author: Al Viro Date: Tue May 12 01:23:29 2026 -0400 configfs_depend_prep(): pass configfs_dirent instead of dentry [ Upstream commit 764682e0118432260191d194edbdaff208260483 ] Again, the only thing it uses dentry for is dentry->d_fsdata; for the recursive call the situation is the same as with configfs_detach_prep() and the same observation about ->s_dentry->d_fsdata applies. Reviewed-by: Jan Kara Reviewed-by: Breno Leitao Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 9489e7189ebb00e189705e932779e708231d17fd Author: Chuck Lever Date: Tue May 26 10:14:03 2026 -0400 xprtrdma: Add request-pool slack for delayed recycling [ Upstream commit 64bf6892057b746c55bcc045b9492741b72d8d27 ] After the previous patch gates req recycling on Send completion, a completed RPC's rpcrdma_req can remain pinned by the sendctx ring until the next signaled Send completion releases it. The transmitted-RPC ceiling is unchanged: xprt_request_get_cong() gates Sends against xprt->cwnd, the RPC/RDMA credit window fed by server-granted credits and capped at re_max_requests. The req pool, however, must exceed max_reqs by enough that this recycle delay does not stall a slot allocation that the credit window would admit. The headroom is bounded. frwr_open() sets re_send_batch to re_max_requests >> 3 -- one in every eight Sends is signaled -- so at most re_send_batch unsignaled Sends can be outstanding before the next signaled completion releases them. That equals max_reqs / 8 reqs in the worst case, with a one-slot floor for small max_reqs values where the right-shift rounds to zero. The sendctx ring and the hardware Send Queue are not enlarged to match. Both are sized in rpcrdma_sendctxs_create() and frwr_query_device() for re_max_requests in-flight Sends, which is the ceiling the credit window enforces. The pool slack does not raise that ceiling -- it only lets allocation keep pace with the credit window during the brief interval in which earlier reqs are pinned waiting for the next signaled completion. At any moment, at most re_send_batch sendctxes are held by unswept unsignaled Sends, leaving the rest of the ring available for newly admitted Sends. Allocate max_reqs + DIV_ROUND_UP(max_reqs, 8) request objects and name the slack calculation at the allocation site so the 1/8 bound stays tied to the Send-signaling batch size. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9f37a6d6ae9e998232e2ba091ab4999cdf967e1b Author: ZhengYuan Huang Date: Wed Mar 25 08:43:38 2026 +0800 btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [ Upstream commit 18d32b0013efba19f7ad3e5b08d7aee813d604a6 ] [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity. Signed-off-by: ZhengYuan Huang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 740ad3d17a281f7764dda4dbeb37cea52e2e31ae Author: Rosen Penev Date: Mon May 25 14:58:40 2026 -0700 netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() [ Upstream commit d3bf9eae486490832bd08fd62ab0ac601f346bd4 ] The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e6c84fe4cf6f98f7b1ad446a42cfcb46bae83f66 Author: Ruoyu Wang Date: Sun Jun 7 15:42:19 2026 +0800 ALSA: es18xx: check control allocation before private data setup [ Upstream commit 422e42b7c2b882ba1d16d4afc8891bcea7c4de93 ] snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure. Signed-off-by: Ruoyu Wang Link: https://patch.msgid.link/20260607074219.3-1-ruoyuw560@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9f13023607f1e95bd098cc49052b0c8955d334f9 Author: Maoyi Xie Date: Thu Jun 4 13:49:49 2026 +0800 hsr: broadcast netlink notifications in the device's net namespace [ Upstream commit a762fabd7ef9a6cc07258684138f9c3f078d0326 ] The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr(). Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260604054949.2999304-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b020390b4ef39adc40c800301042baf812280da1 Author: Guangshuo Li Date: Thu Jun 4 12:31:15 2026 +0800 net: cpsw_new: unregister devlink on port registration failure [ Upstream commit b64f763b607426ac97e44b114f0b8844ac3b86dd ] cpsw_probe() registers devlink before registering the CPSW ports. If cpsw_register_ports() fails, the error path only unregisters the notifiers and then releases the lower level resources. It does not undo the successful cpsw_register_devlink() call, leaving the devlink instance and its parameters registered after probe has failed. Add a devlink cleanup label for the path where devlink registration has already succeeded, and use it when port registration fails. Reviewed-by: Aleksandr Loktionov Reviewed-by: Alexander Sverdlin Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260604043115.1409134-1-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bfcee1f79aaefa90679ad47690107fb7682724ec Author: Dawei Feng Date: Wed Jun 3 18:53:15 2026 +0800 bpf: NUL-terminate replaced sysctl value [ Upstream commit a66e3b5bacf38d6ab29fa05a9754f7a114485605 ] When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports. Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260603105317.944304-2-dawei.feng@seu.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a1ed7f0ffc32f2dbc4bfefc072d6d61346e8fcbc Author: Li RongQing Date: Mon Jun 1 05:58:18 2026 -0400 RDMA/mlx5: Fix state and counter desync on loopback enable failure [ Upstream commit 0d32eabccbe4b2f8d45be3192c5f3c76c8af703d ] In mlx5_ib_enable_lb(), dev->lb.enabled was unconditionally set to true even if mlx5_nic_vport_update_local_lb() failed. Fix this by only setting dev->lb.enabled on success. On failure, roll back the reference counters and return the error. Link: https://patch.msgid.link/r/20260601095818.2227-1-lirongqing@baidu.com Signed-off-by: Li RongQing Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 82ffdd7275506e6b1501d5028ca205831206495c Author: Thiyagarajan Pandiyan Date: Fri Jun 5 11:13:07 2026 +0530 wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer notifications [ Upstream commit dfb67ae569bf0726187725b1ef8d89377778861e ] Currently, ie_len in cfg80211_notify_new_peer_candidate is defined as 1-byte field, capping the maximum IE list size at 255 bytes. When a large beacon is received, the IE list is truncated, passing incomplete data to wpa_supplicant. This causes supplicant to fail parsing the IEs. Increasing the size of ie_len to allow the full length of the IE list to be forwarded properly. Signed-off-by: Thiyagarajan Pandiyan Link: https://patch.msgid.link/20260605054307.427874-1-thiyagarajan@aerlync.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f03b439b63f97dcb26e486e0be5f6063f0e22fb9 Author: Rosen Penev Date: Wed Jun 3 12:25:11 2026 -0700 ipmi: si: Use platform_get_irq_optional() to retrieve interrupt [ Upstream commit 39851b7e580a65bee732e5364f0efb974b242370 ] Use platform_get_irq_optional() to retrieve the interrupt resource instead of directly parsing and mapping the OF node via irq_of_parse_and_map(). This is the standard pattern for platform devices. irq_of_parse_and_map() requires ire_dispose_mapping(), which is missing. Assisted-by: Antigravity:Gemini-3.5-Flash Signed-off-by: Rosen Penev Message-ID: <20260603192511.6869-1-rosenp@gmail.com> [Handle a negative return from platform_get_irq_optional() to mean no interrupt is assigned.] Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 9b178afae13766e22a856de1b664900404cd68d2 Author: Andrei Faleichyk Date: Thu Jun 4 01:33:13 2026 +0400 ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP [ Upstream commit 3580bc53520ce4efc94ece5886ad3670b93667ba ] The internal microphone on ASUS VivoBook X509DAP (subsystem ID 0x1043:0x197e) is not detected without a quirk entry. Add ALC256_FIXUP_ASUS_MIC_NO_PRESENCE to fix the issue. Signed-off-by: Andrei Faleichyk Link: https://patch.msgid.link/20260603213313.6298-1-andrei.faleichyk@noogadev.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6a266f063a3904185f951ea4fc7709adf54f6f1e Author: Michael Walle Date: Thu May 7 11:09:34 2026 -0500 clk: keystone: don't cache clock rate [ Upstream commit a80b32a140c8612bbaed27009c383d43304db6d5 ] The TISCI firmware will return 0 if the clock or consumer is not enabled although there is a stored value in the firmware. IOW a call to set rate will work but at get rate will always return 0 if the clock is disabled. The clk framework will try to cache the clock rate when it's requested by a consumer. If the clock or consumer is not enabled at that point, the cached value is 0, which is wrong. Thus, disable the cache altogether. Signed-off-by: Michael Walle Reviewed-by: Kevin Hilman Reviewed-by: Randolph Sapp Reviewed-by: Nishanth Menon Signed-off-by: Antonios Christidis Reviewed-by: Brian Masney Link: https://patch.msgid.link/20260507-clk-sci-v2-1-38f59b48777a@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 0e2eaa000e4e5ad46b7cf8fcf1e4a2585ef8b5a8 Author: Mathias Nyman Date: Wed Jun 3 12:11:29 2026 +0300 xhci: Prevent queuing new commands if xhci is inaccessible [ Upstream commit 82b70c799281cc24506085be978b829149ba0ca4 ] Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring. Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260603091132.1110849-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6bf5158af52a5293e9160d8f2992c629ca14aa7d Author: David Yang Date: Sat May 30 08:39:14 2026 +0800 net: dsa: sja1105: flower: reject cross-chip redirect [ Upstream commit cfa5274a5dc2a23b957da5dc806d2ac0c7a66af0 ] dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here. Signed-off-by: David Yang Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260530003940.2000994-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3b4b647313757a275be7f7f9d0415d0a90acf73 Author: Cássio Gabriel Date: Tue Jun 2 08:18:39 2026 -0300 ALSA: seq: oss: Reject reads that cannot fit the next event [ Upstream commit 611f538253d970f4d152003841544e875828d015 ] snd_seq_oss_read() checks whether the next queued OSS sequencer event fits in the remaining userspace buffer before removing it from the read queue. The check is inverted. It currently stops when the event is smaller than the remaining buffer, so a normal 4-byte event is not copied for an 8-byte read buffer. Conversely, an 8-byte event can be copied for a smaller read count. Break only when the remaining userspace buffer is smaller than the next event, and report -EINVAL if no complete event has been copied. This prevents an undersized read from looking like end-of-file while leaving the event queued for a later read with a large enough buffer. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260602-alsa-seq-oss-read-size-check-v1-1-10e59b1742e0@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4d3ba021c4cf800c347deaa733daa322a9c6e869 Author: Cássio Gabriel Date: Mon May 25 14:18:03 2026 -0300 ASoC: codecs: rk3328: Use managed GPIO and clock helpers [ Upstream commit 0cf3489bba9ad13aae052232e223e19a620fe7a7 ] rk3328_platform_probe() acquires the mute GPIO with gpiod_get_optional() but never releases it. It also enables mclk and pclk manually while relying on probe error labels for unwind, and the driver has no platform remove callback to disable those clocks after a successful unbind. This path has already needed fixes for missing clock unwinds on probe errors. Use devm_gpiod_get_optional() and devm_clk_get_enabled() so the GPIO and enabled clock lifetimes are tied to the device. This removes the manual error labels and makes both probe failure and driver unbind follow the normal devres cleanup path. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260525-asoc-rk3328-devm-resources-v1-1-2abde0006f89@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 12312c5a28ce04c0bc7a6741168f678be2bb913f Author: Simon Xue Date: Tue Apr 28 18:05:31 2026 +0200 iommu/rockchip: disable fetch dte time limit [ Upstream commit 8d4346ecd4950ae08cc76a6de327c264e846758c ] Disable the Bit 31 of the AUTO_GATING iommu register, as it causes hangups with the RGA3 (Raster Graphics Acceleration 3) peripheral. The RGA3 register description of the TRM already states that the bit must be set to 1. The vendor kernel sets the bit unconditionally to 1 to fix VOP (Video Output Processor) screen black issues. This patch squashes the 2 vendor kernel commits with the following commit messages: Master fetch data and cpu update page table may work in parallel, may have the following procedure: master cpu fetch dte update page tabl | | (make dte invalid) <- zap iotlb entry | | fetch dte again (make dte invalid) <- zap iotlb entry | | fetch dte again (make dte invalid) <- zap iotlb entry | | fetch dte again (make iommu block) <- zap iotlb entry New iommu version has the above bug, if fetch dte consecutively four times, then it will be blocked. Fortunately, we can set bit 31 of register MMU_AUTO_GATING to 1 to make it work as old version which does not have this issue. This issue only appears on RV1126 so far, so make a workaround dedicated to "rockchip,rv1126" machine type. iommu/rockchip: fix vop blocked and screen black on RK356X and RK3588 RK3568 and RK3588 has the same issue as RV1126/RV1109 that caused by dte fetch time limit, So we can set BIT(31) of register 0x24 default to 1 as a workaround. Signed-off-by: Simon Xue Signed-off-by: Sven Püschel Acked-by: Heiko Stuebner Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 78d066ecac9ce50441d4affae0df2093c4c3e62e Author: Wentao Liang Date: Thu May 28 08:00:19 2026 +0000 net: qrtr: fix node refcount leak on ctrl packet alloc failure [ Upstream commit 3b09ff54114566864eea59020f6b69c5bb325b9d ] qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference. Signed-off-by: Wentao Liang Reviewed-by: Alexander Lobakin Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260528080019.1176700-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 533a08ea11217100cec7a0ed903cb9b9c892d6f1 Author: liyouhong Date: Tue Apr 28 10:09:35 2026 +0800 ata: ahci: fail probe if BAR too small for claimed ports [ Upstream commit c4086c6e1af757e1ff26fa2d2926b3ec0195de79 ] When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. Reported-by: liyouhong Closes: https://lore.kernel.org/all/20260422080322.1006592-1-dayou5941@163.com/ Suggested-by: Damien Le Moal Suggested-by: Niklas Cassel Reviewed-by: Damien Le Moal Signed-off-by: liyouhong [cassel: commit log] Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 7ebc6b90e276d2cf12542c65393f77d391240f8e Author: Cezary Rojewski Date: Mon May 25 22:18:01 2026 +0200 ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive [ Upstream commit eb7107264da8545ba7381a76818bae553e1fd1e4 ] Revert changes done in commit 489db5d94150 ("ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined") and add pm_runtime_status_suspended() check. The suspended-check addresses regulator's "unbalanced disables" warning during driver removal even when CONFIG_PM is enabled. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260525201801.1336936-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a4af172225f8fceaa416ecb243dc293c1cb6fabf Author: Rosen Penev Date: Tue May 26 13:22:47 2026 -0700 net: ibm: emac: Reserve VLAN header in MJS limit [ Upstream commit 0906c117f81c2ae6e6dbfa82719f79c75e1c9325 ] The IBM EMAC programs its Maximum Jumbo Size (MJS) drop threshold from ndev->mtu directly. The hardware sizes the threshold against the L2 frame minus the ethernet header, but does not discount the 802.1Q tag, so a frame carrying a VLAN tag and a full 1500-byte payload exceeds MJS by exactly 4 bytes and is dropped. This is normally hidden because JPSM (and therefore the MJS check) only engages when the MTU is raised above ETH_DATA_LEN. With the qca8k DSA tagger the conduit MTU is bumped by QCA_HDR_LEN to 1502 during dsa_conduit_setup(), which is enough to enable JPSM and expose the off-by-VLAN-tag in the limit. Pad MJS by VLAN_HLEN so a VLAN-tagged full-MTU frame passes. Reported on Meraki MX60 (qca8k switch): tagged VLAN traffic drops at 1500-byte payload, while 1496 bytes works and untagged 1500 bytes works. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260526202247.13823-1-rosenp@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4b61b46c72716c51899e061401723a05b7961d14 Author: Sanjay Chitroda Date: Tue May 5 23:16:32 2026 +0530 iio: accel: mma8452: switch to non-devm request_threaded_irq() [ Upstream commit 0a6726ec20cd4c0101f2de0ca485a11676224dea ] Avoid using devm_request_threaded_irq() as the driver requires explicit error-handling path(s). Using devm_* API together with goto-based unwinding breaks the expected LIFO resource release model. Add explicit IRQ cleanup in the driver teardown paths to follow kernel resource management conventions. Signed-off-by: Sanjay Chitroda Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5fc7a10746ad91c4c7ce370cc6cf2d31beaad028 Author: Rik van Riel Date: Wed May 27 11:13:01 2026 -0400 perf/ftrace: Fix WARNING in __unregister_ftrace_function [ Upstream commit 9581123304b23049437324038698af9fb56ee663 ] perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success. Link: https://patch.msgid.link/20260527111301.2d0d8256@fangorn Signed-off-by: Rik van Riel Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 4a70327b7c75be3654d2f1b4b1d4ea81230cda90 Author: Osama Abdelkader Date: Sun May 10 18:29:39 2026 +0200 mmc: davinci: fix mmc_add_host order in probe [ Upstream commit d04e0151d316edbdb4f0397a9b92a1936e4a1421 ] mmc_add_host() makes the host visible to the MMC core. Register the interrupt handlers and advertise MMC_CAP_SDIO_IRQ before that, so the core cannot start using the host before IRQ handling is set up. Signed-off-by: Osama Abdelkader Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ff885a7647aa95e3f39ef8e9bcf9804492c95ba6 Author: Bard Liao Date: Wed May 20 10:57:20 2026 +0800 soundwire: only handle alert events when the peripheral is attached [ Upstream commit 38cd651ebce7065a81c7e950d9e2ea1572304605 ] It doesn't make sense to handle an alert event when the peripheral is not attached. The slave->status could be SDW_SLAVE_ATTACHED or SDW_SLAVE_ALERT when it is attached on the bus. Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260520025720.1999367-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 43303d0c9dd1d8349406710aec17d82e5907d76d Author: Cezary Rojewski Date: Thu May 28 10:34:42 2026 +0200 ASoC: Intel: catpt: Complete coredump handling [ Upstream commit 7e5d59f407bc39d43b350cc45f7880647429eb5d ] An exception may occur during the firmware booting procedure. In such case the firmware sends COREDUMP_REQUESTS and expects the driver to dump relevant information and finish with the COREDUMP_RELEASE write. To distinguish such situation from generic timeout, always signal fw_ready completion when a coredump request is received and translate it to -EREMOTEIO in catpt_boot_firmware(). The "FW READY" print makes the success clearly visible even when the event-traces are not enabled. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260528083444.1439233-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3356746c632b364f737eb4a785d41536b63d11d2 Author: Alexandre Courbot Date: Wed May 27 20:52:17 2026 +0900 scripts: modpost: detect and report truncated buf_printf() output [ Upstream commit d7231d8cb262b1e350c00271bf53d54414b4f3b1 ] buf_printf() uses a fixed-size stack buffer. vsnprintf() returns the number of bytes that *would* have been written to that buffer, which can be larger than the size of said buffer if the formatted string is too long. The problem is that whenever this happens buf_printf() currently passes this length, unchecked, to buf_write(), which silently reads past the stack buffer and copies invalid data into the output buffer. Fix this by detecting vsnprintf() failures and truncations before appending to the output buffer, and report a fatal error instead of producing corrupt symbol names. Signed-off-by: Alexandre Courbot Link: https://patch.msgid.link/20260527-nova-exports-v2-1-06de4c556d55@nvidia.com Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit d4f2f6c15ae4d42b2729d3ea238b96aaf78f6985 Author: Viacheslav Dubeyko Date: Tue May 19 15:28:12 2026 -0700 hfs: rework hfsplus_readdir() logic [ Upstream commit 7fde7e806657fbe0d33f489521b488eed94f9b39 ] The xfstests' test-case generic/637 fails with error: FSTYP -- hfs PLATFORM -- Linux/x86_64 kvm-xfstests 6.15.0-rc4-xfstests-g00b827f0cffa #1 SMP PREEMPT_DYNAMIC Fri May 25 MKFS_OPTIONS -- /dev/vdc MOUNT_OPTIONS -- /dev/vdc /vdc QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Likewise HFS+, currently, HFS has very complicated and fragile logic of rd->file->f_pos correction in hfs_delete_cat(). This patch removes this logic and it stores the current pos into hfs_readdir_data. Finally, if rd->pos == ctx->pos then hfs_readdir() tries to find the position in b-tree's node by means of hfs_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #55 SMP PREEMPT_DYNAMIC Tue May 19 15:18:02 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 32s ... 31s Ran: generic/637 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/65 cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260519222811.1311071-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 3a8c1efc0fd3abb2d2b1254315f36db03abc88eb Author: ikaros Date: Wed May 27 20:10:18 2026 +0200 ACPICA: add boundary checks in two places [ Upstream commit bdc35754012906dbf094be104b103ca3adfef6f7 ] Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/cfdc96896d8d Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5180044.0VBMTVartN@rafael.j.wysocki Signed-off-by: Sasha Levin commit 816badec122fe01d05265f2d306212739f5d3fdb Author: ikaros Date: Wed May 27 20:04:46 2026 +0200 ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() [ Upstream commit b2e21fe8c3361c3d0d57ee56d359bea9b51fda3d ] Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows. Link: https://github.com/acpica/acpica/commit/975cb20c7992 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2481429.NG923GbCHz@rafael.j.wysocki Signed-off-by: Sasha Levin commit fad537538cdfcdc51e41db61bbf9ebe5ed9427eb Author: Weiming Shi Date: Wed May 27 20:05:42 2026 +0200 ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() [ Upstream commit f8d14b7bb0063bbbd86c0e4d73edb8cea7b362bc ] acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing. Link: https://github.com/acpica/acpica/commit/f3f111b9013b Reported-by: Xiang Mei Reported-by: Weiming Shi Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5674388.Sb9uPGUboI@rafael.j.wysocki Signed-off-by: Sasha Levin commit 087eed8b347e14864f8806fa1f5976c7dc2c6792 Author: ikaros Date: Wed May 27 20:04:06 2026 +0200 ACPICA: Add validation for node in acpi_ns_build_normalized_path() [ Upstream commit 96b2b616870e46e2bc04efec03879683a0036e66 ] Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities. Link: https://github.com/acpica/acpica/commit/b35adf49e89a Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/118666237.nniJfEyVGO@rafael.j.wysocki Signed-off-by: Sasha Levin commit c82d4adeeb5acbd5231f082da11155017a4c241e Author: ikaros Date: Wed May 27 20:09:24 2026 +0200 ACPICA: Add package limit checks in parser functions [ Upstream commit d27d48a528e437aed690f977e69a6fe73fe82ab5 ] Add package limit checks in parser functions to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/b31b45af2122 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3212937.CbtlEUcBR6@rafael.j.wysocki Signed-off-by: Sasha Levin commit 7af2da201623ab5bc0773bd3eeb2f2345cfa1c4a Author: ikaros Date: Wed May 27 20:03:26 2026 +0200 ACPICA: validate handler object type in two places [ Upstream commit c5296da2d516707862f8a2dbb4b515f777e5294f ] ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler(). Link: https://github.com/acpica/acpica/commit/f6fc648a1389 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/48111441.fMDQidcC6G@rafael.j.wysocki Signed-off-by: Sasha Levin commit 4b45d45e63ca6fa0e8843e9bca2dbb4889061e8d Author: ikaros Date: Wed May 27 20:02:49 2026 +0200 ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg() [ Upstream commit 27d27e75ecb752a0b4da848c440bb3a88396ecba ] Improve argument parsing in acpi_ps_get_next_simple_arg() to handle remaining AML data safely. Link: https://github.com/acpica/acpica/commit/ecbb8bcfe301 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2008043.taCxCBeP46@rafael.j.wysocki Signed-off-by: Sasha Levin commit 6da963ed4c3de0963c23809af3194323328080d2 Author: ikaros Date: Wed May 27 20:02:06 2026 +0200 ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) [ Upstream commit 0e2021f49e64b3c8a9aa880d0c62a218bfe147ce ] Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy(). Link: https://github.com/acpica/acpica/commit/d281ec1ac84e Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3760974.R56niFO833@rafael.j.wysocki Signed-off-by: Sasha Levin commit 2350a6f89eca45f9219f37b331e4083f96299996 Author: ikaros Date: Wed May 27 20:01:21 2026 +0200 ACPICA: Prevent adding invalid references [ Upstream commit 6e8c55e13a5e3a9f38921d62924f18ceba3330eb ] Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object(). Link: https://github.com/acpica/acpica/commit/f576898d7814 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4511989.ejJDZkT8p0@rafael.j.wysocki Signed-off-by: Sasha Levin commit 6b9904fc65d82bea4922a33038d075488954bcc9 Author: ikaros Date: Wed May 27 19:59:57 2026 +0200 ACPICA: validate byte_count in acpi_ps_get_next_package_length() [ Upstream commit d49c6ee08365a8596f639da46eb7e71752b0cd42 ] Validate package length reading in acpi_ps_get_next_package_length(). Link: https://github.com/acpica/acpica/commit/40e03f9941e2 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3616255.QJadu78ljV@rafael.j.wysocki Signed-off-by: Sasha Levin commit 1d704a9ba665f8d1598fc6f37a76cbd6547cdcb1 Author: ikaros Date: Wed May 27 20:00:39 2026 +0200 ACPICA: add boundary checks in acpi_ps_get_next_field() [ Upstream commit e15aa60de0256d63df2331bf5a4bc4dd287504cd ] Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/c39183ea84bc Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/24388159.6Emhk5qWAg@rafael.j.wysocki Signed-off-by: Sasha Levin commit 460aed7b408508a2c28ca4fdd8d90a82bb4005aa Author: ikaros Date: Wed May 27 19:59:12 2026 +0200 ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() [ Upstream commit 945e87267cfd90937b3c637f87324cbb56998b72 ] Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments. Link: https://github.com/acpica/acpica/commit/36f22a94cb1b Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/8730924.NyiUUSuA9g@rafael.j.wysocki Signed-off-by: Sasha Levin commit c838d32fbe02a6d426aebf95d2aef97de92ddc43 Author: ikaros Date: Wed May 27 19:53:12 2026 +0200 ACPICA: Fix condition check in acpi_ps_parse_loop() [ Upstream commit 8de27e2d83c0d07ae9443c6304575b0609394bfd ] Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/3b537b92336e Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1959692.tdWV9SEqCh@rafael.j.wysocki Signed-off-by: Sasha Levin commit 345d91c7c60cc3876b8dc04da8a9d8d1468f9824 Author: Jeremy Klarenbeek Date: Tue May 19 10:41:57 2026 +0200 drm/amd/pm/si: Fix updating clock limits from power states [ Upstream commit e6c5d36756e7d4d260e2365fc4d01226f1973152 ] VBIOS can contain conflicting values between: - the maximum allowed clocks and voltages on AC or DC - the clocks and voltages in power states on AC or DC Update maximum clock (and voltage) limits for both AC/DC and take the highest value from the VBIOS limits and the performance/battery power states. Previously this was only done for AC, but is also needed for DC. This commit fixes the behaviour on some laptop GPUs, where the VBIOS limit was set to the lowest possible clock frequency, so the GPU was stuck on the lowest possible power level on battery. Some affected GPUs are: FirePro W4170M (Dell Precision M2800) Radeon HD 8790M (Dell Latitude E6540) and possibly other laptop GPUs. Reviewed-by: Alex Deucher Co-developed-by: Timur Kristóf Signed-off-by: Timur Kristóf Signed-off-by: Jeremy Klarenbeek Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b00f7c1da82a809156f785ed37536c2d2584927d Author: Fernando Fernandez Mancera Date: Sat May 23 12:38:10 2026 +0200 ipv6: addrconf: fix temp address generation after prefix deprecation [ Upstream commit e20d8922aa8fe441d291364c96c2179a005b79ea ] When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA. Reported-by: Łukasz Stelmach Closes: https://lore.kernel.org/netdev/87340td30q.fsf%25steelman@post.pl/ Suggested-by: Ido Schimmel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260523103811.3790-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d65e6b7077517fdd2024ddc2604af4f271f4c90d Author: Uwe Küchler Date: Tue May 26 18:20:33 2026 +0200 ALSA: usb-audio: Add quirk for Novation Mininova [ Upstream commit b2e9d2cbbb71b00faf3e27fb741a27b9ad455edd ] Add a device-specific quirk for the Novation Mininova synthesizer (USB ID 1235:001e) to enable proper recognition and functionality as a MIDI device. Signed-off-by: Uwe Küchler Link: https://patch.msgid.link/20260526162033.7513-1-uwe@kuechler.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3e4cae9f1472ba3c9fe87edee24074618b51f537 Author: Mostafa Saleh Date: Tue May 26 12:53:17 2026 +0000 irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed [ Upstream commit e61654fbc3bc5d07ec9fafe29f33e19b2b5d0fd5 ] When accidentally setting “kvm-arm.vgic_v4_enable=1” on a system that has no MSI controller device tree node and GICv4, it results a panic as “gic_domain” is NULL and the kernel attempts to access it. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Mem abort info: ESR = 0x0000000096000006 CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __irq_domain_instantiate+0x1d4/0x578 lr : __irq_domain_instantiate+0x1cc/0x578 Set vLPI support to false at init time if the host has no ITS, so it propagates properly to kvm_vgic_global_state.has_gicv4. Suggested-by: Marc Zyngier Signed-off-by: Mostafa Saleh Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260526125317.3672297-1-smostafa@google.com Signed-off-by: Sasha Levin commit b5ff97e01e63d51c9a61097d22cf776149853b9c Author: Stepan Ionichev Date: Thu May 21 00:09:24 2026 +0500 iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind [ Upstream commit 929fec2964f71d4b1ac664ee963d8226c5cf01c6 ] iadc_probe() calls enable_irq_wake() after a successful devm_request_irq(), but the driver has no remove callback or matching disable_irq_wake(), so the wake reference count on the IRQ is leaked on module unload or driver unbind. Check the IRQ request error first, then register a devm action that calls disable_irq_wake() so the wake reference is released in the same scope as the enable. While here, drop the inverted "if (!ret) ... else return ret" in favour of the standard "if (ret) return ret;" pattern. Signed-off-by: Stepan Ionichev Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit cda171ee6b72ee7dae3d4158f1d766cb778fb301 Author: Rosen Penev Date: Thu May 7 16:23:23 2026 -0700 mips: cps: Assemble jr.hb with an R2 ISA level [ Upstream commit e5d64f868e484da06f5c141c18c32c01c269625e ] A MIPS allmodconfig built with LLVM can select CPU_MIPS32_R1 together with MIPS_MT_SMP. In that configuration clang invokes the integrated assembler with -march=mips32, and the MIPS MT path in cps-vec.S fails to assemble two jr.hb instructions: arch/mips/kernel/cps-vec.S:376:2: error: instruction requires a CPU feature not currently enabled arch/mips/kernel/cps-vec.S:490:4: error: instruction requires a CPU feature not currently enabled The earlier jr.hb in the same file is already assembled inside a .set MIPS_ISA_LEVEL_RAW scope. The two failing sites are reached after popping back to the file's base ISA level, so LLVM correctly rejects them for an R1 target. Wrap those jr.hb instructions in the same ISA-level push/pop used by the working site. This keeps the MT code unchanged while making the required R2 hazard-branch encoding explicit to the assembler. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev Reviewed-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit acbc829581c790fc8a86084d25d9851a8625b7ff Author: Dario Binacchi Date: Fri May 15 10:22:01 2026 +0200 drm/panel: simple: Add AM-1280800W8TZQW-T00H [ Upstream commit 6acb810ebc5d8dea5c250326c14dc44e32dc8e92 ] Add Ampire, AM-1280800W8TZQW-T00H 10.1" TFT LCD panel timings. Co-developed-by: Michael Trimarchi Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi Reviewed-by: Dmitry Baryshkov Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260515082232.1766586-2-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin commit 78a2ba09fd7501df09239c7e3c311c80c259ed31 Author: Daniel Lezcano Date: Fri Apr 24 18:00:19 2026 +0200 thermal/drivers/tegra/soctherma: Switch to devm cooling device registration [ Upstream commit ee126267bc04bfb03816ae9d71ca24c5bf99e739 ] Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above. Signed-off-by: Daniel Lezcano Signed-off-by: Daniel Lezcano Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260424160019.41710-2-daniel.lezcano@oss.qualcomm.com Signed-off-by: Sasha Levin commit 34b40bd455e63fb5499d6523a38791babbf99e27 Author: Adrian Ng Ho Yin Date: Fri May 22 17:02:54 2026 +0800 clk: socfpga: agilex: implement l3_main_free_clk [ Upstream commit 1e7f56205813a2c48cdb3e9a4b0a24f49fd9a548 ] The AGILEX_L3_MAIN_FREE_CLK is defined in the dt-bindings header but was never implemented in the clock driver. Per the Agilex TRM, l3_main_free_clk has no divider or mux and is a fixed 1:1 derivative of noc_free_clk that clocks most of the interconnect datapath. Signed-off-by: Adrian Ng Ho Yin Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit a09d5136a555ef1c6a6059bf678b245b3af3154b Author: Heiko Carstens Date: Tue May 19 08:20:42 2026 +0200 s390/zcore: Removed unused variables [ Upstream commit 0a2aa995c0a1d363b5f0803862e84834e3876ae2 ] allmodconfig with clang W=1 points out unused global variables: drivers/s390/char/zcore.c:49:23: error: variable 'zcore_reipl_file' set but not used [-Werror,-Wunused-but-set-global] drivers/s390/char/zcore.c:50:23: error: variable 'zcore_hsa_file' set but not used [-Werror,-Wunused-but-set-global] Remove both of them, since there is no point in keeping them. Reviewed-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 7089f935c1b42e6f752dc479b9a9c871c68d0945 Author: Jiayuan Chen Date: Fri May 22 09:16:20 2026 +0800 rds: annotate data-race around rs_seen_congestion [ Upstream commit 67636cab273ed0c0b0f2adab6c9369a471cb7966 ] rs_seen_congestion is read in rds_poll() and written in rds_sendmsg() and rds_poll() without any lock. Use READ_ONCE()/WRITE_ONCE() to annotate these lockless accesses and silence KCSAN. Reported-by: syzbot+fbf3648ae7f5bdb05c59@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a0f8d94.050a0220.6b33c.0000.GAE@google.com/ Signed-off-by: Jiayuan Chen Reviewed-by: Allison Henderson   Tested-by: Allison Henderson Link: https://patch.msgid.link/20260522011621.304470-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 64ca5839916176c3451f61a2c7178033423c67d7 Author: Maoyi Xie Date: Wed May 20 16:42:36 2026 +0800 rds: filter RDS_INFO_* getsockopt by caller's netns [ Upstream commit c96a5209dda666004b8ee1ed7f0d493d09a4f200 ] The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1. Suggested-by: Allison Henderson Suggested-by: Simon Horman Reviewed-by: Allison Henderson Co-developed-by: Praveen Kakkolangara Signed-off-by: Praveen Kakkolangara Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260520084236.2724349-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5f1ca7205275686e6ec696e7838debe39a389625 Author: Chenguang Zhao Date: Fri May 22 10:29:10 2026 +0800 netlabel: fix IPv6 unlabeled address add error handling [ Upstream commit 56872b930feee7ae07b9720ca950dd9fa65596ee ] netlbl_unlhsh_add_addr6() always returned zero after netlbl_af6list_add(), masking failures such as duplicate IPv6 static label entries. Signed-off-by: Chenguang Zhao Acked-by: Paul Moore Link: https://patch.msgid.link/20260522022910.398416-1-zhaochenguang@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c07dca3dbd9c4b651f9983d828ca4033d489a03a Author: Venkat Rao Bagalkote Date: Tue Apr 28 11:45:40 2026 +0530 char/nvram: Remove redundant nvram_mutex [ Upstream commit e8c715f3a7dae43fabae261493a26474fec11863 ] The global nvram_mutex in drivers/char/nvram.c is redundant and unused, and this triggers compiler warnings on some configurations. All platform-specific nvram operations already provide their own internal synchronization, meaning the wrapper-level mutex does not provide any additional safety. Remove the nvram_mutex definition along with all remaining lock/unlock users across PPC32, x86, and m68k code paths, and rely entirely on the per-architecture nvram implementations for locking. Reviewed-by: Arnd Bergmann Suggested-by: Arnd Bergmann Tested-by: Tellakula Yeswanth Krishna Signed-off-by: Venkat Rao Bagalkote Tested-by: yeswanth Reviewed-by: Ritesh Harjani (IBM) Link: https://patch.msgid.link/20260428061540.73668-1-venkat88@linux.ibm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0585c38755e8188cc4885c7904c8adf755b94a29 Author: Christian Marangi Date: Tue May 19 18:49:02 2026 +0200 usb: host: add ARCH_AIROHA in XHCI MTK dependency [ Upstream commit ffeaf31f05d664581aa436d9cb92b4d1d8d301ce ] Airoha SoC use the same register map and logic of the Mediatek xHCI driver, hence add it to the dependency list to permit compilation also on this ARCH. Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260519164903.31258-1-ansuelsmth@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4bce4a6f6318035d77d6b6199527b1950bb015f4 Author: Marco Felsch Date: Tue May 19 11:57:00 2026 +0200 serial: 8250: fix possible ISR soft lockup [ Upstream commit 0c6bf45e5a345cc3b9ffbeaf9083ecac3c2293eb ] There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected. Signed-off-by: Marco Felsch Link: https://patch.msgid.link/20260519-v7-1-topic-serial-8250-v1-1-56b04293a246@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d7b33afbf9b54b61cb423af9663df54eae11d3b1 Author: Stepan Ionichev Date: Sat May 9 16:06:36 2026 +0500 usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log [ Upstream commit 5bf5e3fba9bc7dfd69701521dbe9809f8ccbdb02 ] goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: if (dev->gadget.speed != USB_SPEED_UNKNOWN && dev->driver && dev->driver->resume) { spin_unlock(&dev->lock); dev->driver->resume(&dev->gadget); ... } but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: if (stat & INT_USBRESET) { ACK(INT_USBRESET); INFO(dev, "USB reset done, gadget %s\n", dev->driver->driver.name); } If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound. Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260509110636.19762-1-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8461eda5af77c44d216cec66455bd5b01ee35c9a Author: Oliver Neukum Date: Wed Apr 29 11:44:04 2026 +0200 usb: core: hcd: fix possible deadlock in rh control transfers [ Upstream commit d5559f43d76b398392b26a15cbc16d731969cd1c ] >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged. Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260429094413.181038-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2b477ee5cc9c2670185ffd82911a20e1760008c2 Author: Adrian Wowk Date: Mon Apr 13 20:00:49 2026 -0500 usbip: vhci_hcd: fix NULL deref in status_show_vhci [ Upstream commit bc150783542ba2e7c1257d1299c6f3269bdba270 ] platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration. Signed-off-by: Adrian Wowk Reviewed-by: Shuah Khan Link: https://patch.msgid.link/20260414010050.158064-2-dev@adrianwowk.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6db7f0ba365786304558db6a3d52013ae176e03e Author: Christoph Hellwig Date: Mon May 11 09:16:52 2026 +0200 isofs: handle set_blocksize failures [ Upstream commit 25ef4c4d9f0e96fb89c0ae0d7127c3f12a31bc32 ] isofs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-8-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit a2a3592ebf3920dd6f2b754d2bb7361f54764e84 Author: Christoph Hellwig Date: Mon May 11 09:16:55 2026 +0200 omfs: handle set_blocksize failures [ Upstream commit 18c3d6fcb557f920c9143711497625e70153874c ] omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-11-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit f7b0cde62edb8ceff8bcc17ba3f1b086646fff89 Author: Christoph Hellwig Date: Mon May 11 09:16:47 2026 +0200 hpfs: handle set_blocksize failures [ Upstream commit a405996f23e04942aad064ab8d50c55827482872 ] hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-3-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e2712fa5c02cd1b3e40d45bc8ce581f3c67bf4b4 Author: Christoph Hellwig Date: Mon May 11 09:16:49 2026 +0200 jfs: handle set_blocksize failures [ Upstream commit 05107f5602751fcfd3d108c1f579eb45aabead52 ] jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-5-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit de8bd760ca0c2a3f337bbafbeb1dcad0853787cc Author: Christoph Hellwig Date: Mon May 11 09:16:48 2026 +0200 qnx4: handle set_blocksize failures [ Upstream commit c7d911ea1cc9a63b07e52f5e75b263be0615b289 ] qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-4-hch@lst.de Acked-by: Anders Larsen Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0a81861c26d27478e61345291163fca00216c37c Author: Christoph Hellwig Date: Mon May 11 09:16:53 2026 +0200 minix: handle set_blocksize failures [ Upstream commit 38a03dc2bc71e7e0746cdb9ef5e9947f72470c67 ] minix uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-9-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 965b53ee91cfda3faf8bd0d0ffff5f70c7d1c479 Author: Christoph Hellwig Date: Mon May 11 09:16:46 2026 +0200 bfs: handle set_blocksize failures [ Upstream commit 2430e3380936df0b648af720cae624eef035a2d1 ] bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-2-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit f5d65b2811872e8f8b424860fa7c2500afbbc5a6 Author: Christoph Hellwig Date: Mon May 11 09:16:51 2026 +0200 affs: handle set_blocksize failures [ Upstream commit 0861182af5983a39bd2a891966436c5679b74a45 ] affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-7-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit cf6a5901a413ecc603aee13716c078d01f9b4209 Author: Christoph Hellwig Date: Mon May 11 09:16:50 2026 +0200 befs: handle set_blocksize failures [ Upstream commit 7597d42a25332617a3dfe596758d780ec6c028d7 ] befs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-6-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit b3621acf640e32dcb986d9b3767f2387f29dad05 Author: Allison Henderson Date: Sun May 17 18:24:33 2026 -0700 net/rds: Don't sleep inside rds_ib_conn_path_shutdown [ Upstream commit 16f48efaeb6991193fb7775c577f06f5b20b0c90 ] New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds. Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260518012443.2629206-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ec9cea4ed12073c26674c5445659e5649c7087c5 Author: Eric Dumazet Date: Tue May 19 09:46:18 2026 +0000 net/sched: sch_drr: make cl->quantum lockless [ Upstream commit a4d880b85089e12a5f2e8e2fee386310cec5b99a ] cl->quantum does not need to be protected by RTNL or qdisc spinlock. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260519094618.2632073-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35f9f11740515a10b084adfb1ce691351f2452ab Author: Eric Dumazet Date: Tue May 19 09:55:40 2026 +0000 net: bridge: remove stale rcu_barrier() in br_multicast_dev_del() [ Upstream commit 25ae123db10ba9ab890b56bcdb0a4363aee8529a ] This rcu_barrier() came from a time call_rcu() calls were used in net/bridge/br_multicast.c. Now kfree_rcu() is there, we can remove this problematic rcu_barrier() which causes extreme RTNL pressure in many syzbot reports. INFO: task syz-executor:77945 is blocked on a mutex likely owned by task kworker/u1024:5:36537. task:kworker/u1024:5 state:D stack:24616 pid:36537 tgid:36537 ppid:2 task_flags:0x4208060 flags:0x00080000 last_sleep:612797637337 Workqueue: netns cleanup_net Call Trace: [] context_switch+0xf2a/0x1730 kernel/sched/core.c:6483 [] __schedule+0x1133/0x43a0 kernel/sched/core.c:8411 [] __schedule_loop kernel/sched/core.c:8514 [inline] [] schedule+0xab/0x260 kernel/sched/core.c:8529 [] schedule_timeout+0xc3/0x2b0 kernel/time/sleep_timeout.c:75 [] do_wait_for_common kernel/sched/completion.c:100 [inline] [] __wait_for_common kernel/sched/completion.c:121 [inline] [] wait_for_common kernel/sched/completion.c:132 [inline] [] wait_for_completion+0x2c7/0x5d0 kernel/sched/completion.c:153 [] rcu_barrier+0x49f/0x620 kernel/rcu/tree.c:3888 [] br_multicast_dev_del+0x303/0x350 net/bridge/br_multicast.c:4459 [] br_dev_uninit+0x1c/0x40 net/bridge/br_device.c:157 [] unregister_netdevice_many_notify+0x1c1c/0x2300 net/core/dev.c:12599 [] ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] [] ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248 Signed-off-by: Eric Dumazet Reviewed-by: Jakub Sitnicki Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260519095540.2643318-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 473ee891ea0036044ae48d3b8b7ea816a9c0d55c Author: Jan Volckaert Date: Sun May 17 17:32:36 2026 +0200 net: usb: qmi_wwan: add MeiG SRM813Q [ Upstream commit 9758c11fc6c138a79a28a5659feeaa3abde7aa6a ] Add support for the Qualcomm Technology Snapdragon X35-based MeiG SRM813Q module. The module can be put in different modes via AT commands to enable/disable GPS functionality: MODEM - PPP mode(2dee:4d63): AT+SER=1,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: MODEM If#= 3: AT P: Vendor=2dee ProdID=4d63 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms NMEA mode(2dee:4d64): AT+SER=51,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: NMEA If#= 3: AT P: Vendor=2dee ProdID=4d64 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Jan Volckaert Link: https://patch.msgid.link/20260517153237.55995-2-janvolck@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 84e8fcadcdd94f07a09a72dae30659e65466ce58 Author: Yury Norov Date: Mon Apr 27 18:57:05 2026 -0400 bitfield: wire __bf_shf to __builtin_ctzll [ Upstream commit 09472f591aa0b72c2dd6c693f48b2d6fea66c7ba ] __bf_shf() is currently based on built-in ffsll. It's more straightforward to wire it to __builtin_ctzll, which makes it a pure rename. Worth to notice that __builtin_ffsll() is buggy on GCC before 14.1: int main() { sizeof(struct { int t : !(__builtin_ffsll(~0ULL) + 1 < 0); }); } test.c: In function 'main': test.c:3:21: error: bit-field 't' width not an integer constant 3 | int t : !(__builtin_ffsll(~0ULL) + 1 < 0); | ^ Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124699 Reported-by: Matt Coster Closes: https://lore.kernel.org/oe-kbuild-all/202603222211.A2XiR1YU-lkp@intel.com/ Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit 026637b864b16dfae238e7e1accded820a3d7ae8 Author: Miri Korenblit Date: Wed May 13 18:26:56 2026 +0300 wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed [ Upstream commit 7a8a3ff2815501f78f494808355ddf37e08647d0 ] In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260513182548.6a25f3a0a6ec.I83d1f2a7eed20200a78a62757c6b193e3bab892b@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4a754704698017ced0b657c92b468035faad00ed Author: Sudeep Holla Date: Sun May 17 20:02:41 2026 +0100 firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size [ Upstream commit 56e7e64cdd0e7209a58c8ec66028d63387402919 ] BASE_ERROR_EVENT carries a variable number of message reports, with the count encoded in error_status. The notification parser used that count without checking whether the received payload contained all reported entries. Reject truncated payloads before copying the report array. Link: https://patch.msgid.link/20260517-scmi_fixes-v1-2-d86daec4defd@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit e8dc28f43c54754e12ed3fba5a84a1ce2ec29c9a Author: Leonardo Bras Date: Mon Apr 27 15:01:26 2026 +0100 arm64/daifflags: Make local_daif_*() helpers __always_inline [ Upstream commit 827ce94e0897a70241abf810b1d3d7d083053a39 ] Make sure those helpers are always inlined and instrumentation safe. Suggested-by: Mark Rutland Signed-off-by: Leonardo Bras Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 946d4abb8d46dfb79908f35e697630c530344c9f Author: Pierre Barre Date: Tue May 12 13:20:32 2026 +0000 9p: invalidate readdir buffer on seek [ Upstream commit e661e17ddbed524b5fbda789a091b48b6b677067 ] The per-fid readdir buffer (fid->rdir) is populated lazily and only refilled when fully drained (rdir->head == rdir->tail). userspace lseek() on a directory fd updates file->f_pos via generic_file_llseek() but does not touch the cached buffer, so the next getdents() iterates the stale cache and emits entries from the previous position instead of the one the caller asked for. Track the file position the cached data corresponds to in struct p9_rdir, and drop the cache on entry to iterate_shared when it no longer matches ctx->pos. The 9p protocol's Tread/Treaddir already take an arbitrary offset on every request, so a refill at the new position is always legal; no .llseek override or seek restriction is needed. Reported-by: Pierre Barre Link: https://lore.kernel.org/v9fs/496d10b9-40fe-4f81-8014-37497c37ff63@app.fastmail.com/ Signed-off-by: Pierre Barre Message-ID: <20260512132032.369281-2-pierre@barre.sh> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 7eb2aaf1617ed4c2e5f30e29f8520a8a9324aea1 Author: Cássio Gabriel Date: Tue May 19 00:20:41 2026 -0300 ALSA: usx2y: Drain pending US-428 pipe-4 output commands [ Upstream commit 18977c0dd722f52217027ff75de2811c53cce2cc ] The US-428 pipe-4 output path submits at most one pending p4out entry from the shared-memory ring per input interrupt. If userspace queues more than one command before the interrupt handler runs, later commands remain pending until later input interrupts, even when async pipe-4 URBs are available. Drain pending entries while idle async URBs are available. Copy each command into the existing per-URB async buffer before submission, so the submitted transfer does not depend on a userspace-mapped ring slot remaining unchanged after p4out_sent is advanced. Also update p4out_sent only after usb_submit_urb() succeeds, so a failed submission is not reported as sent. This keeps the shared-memory ABI unchanged and fixes only the local queue-draining behavior. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260519-alsa-usx2y-p4out-drain-v1-1-8f0a4550bae2@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bada843772c696677185c8581945c8ea4754320f Author: Joonwon Kang Date: Sun May 10 05:41:11 2026 +0000 mailbox: Make mbox_send_message() return error code when tx fails [ Upstream commit 96a3d2f3167f5644b30e60171898e67123c3c2c6 ] When the mailbox controller failed transmitting message, the error code was only passed to the client's tx done handler and not to mbox_send_message() in blocking mode. For this reason, the function could return a false success. This commit resolves the issue by introducing the tx status and checking it before mbox_send_message() returns. This commit works with the premise that the multi-threads' access to a channel in blocking mode is serialized by clients, not by the mailbox APIs, since the current mbox_send_message() in blocking mode does not support multi-threads. Signed-off-by: Joonwon Kang Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit ebf3b0014341952823a8702088b1e202df1f2060 Author: Chenguang Zhao Date: Fri Apr 10 15:40:46 2026 +0800 RDMA/mlx5: Use QP port when decoding responder CQEs [ Upstream commit 194762e6e436acde0f8f6aef44200b0058c36791 ] The responder CQE path determines the link layer via rdma_port_get_link_layer(). Use qp->port instead of hardcoding port 1, which can mis-decode completions on multi-port devices. Signed-off-by: Chenguang Zhao Link: https://patch.msgid.link/20260410074046.2044595-1-zhaochenguang@kylinos.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 40cb9035752c0a1ee38b1082e1ce20789f0db5df Author: Alessandro Baldi Date: Sun May 17 11:14:15 2026 +0200 media: imon: Add iMON VFD HID OEM v1.2 key mappings [ Upstream commit d97d13c24d7893abcfb80d38630ce74daaa1434c ] Add Vol+/Vol-/Mute panel button mappings for iMON VFD HID OEM v1.2. This version differs in the codes that generate the KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE events. Signed-off-by: Alessandro Baldi Signed-off-by: Sean Young Signed-off-by: Sasha Levin commit 3711d3069c81b171010621c18e8a796826dc6171 Author: Thorsten Blum Date: Sun Apr 12 11:56:43 2026 +0200 crypto: atmel-ecc - add support for atecc608b [ Upstream commit b668edaf8dcc8d09f6f1e71797422b44d4bd22a3 ] Tested on hardware with an ATECC608B at 0x60. The device binds successfully, passes the driver's sanity check, and registers the ecdh-nist-p256 KPP algorithm. The hardware ECDH path was also exercised using a minimal KPP test module, covering private key generation, public key derivation, and shared secret computation. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a9531808602b949aa8f58542a5805fb742e45e18 Author: Lukas Wunner Date: Wed May 6 15:27:49 2026 +0200 crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y [ Upstream commit c64ba13e2033c3c6dc1a097bf35f9f1fe457c3f7 ] Andrew reports build breakage of arm allmodconfig, reproducible with gcc 14.2.0 and 15.2.0: crypto/ecc.c: In function 'ecc_point_mult': crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] gcc aggressively inlines functions called by ecc_point_mult() (without there being any explicit inline declarations), which pushes stack usage close to the limit imposed by CONFIG_FRAME_WARN. allmodconfig implies CONFIG_KASAN_STACK=y, which increases the stack above that limit. In the bugzilla entry linked below, gcc maintainers explain that gcc estimates extra stack usage caused by inlining, but ASAN instrumentation is added in post-IPA passes and thus the inlining heuristics cannot account for it. It could be argued that -Werror=frame-larger-than=1280 instructs the compiler to avoid inlining beyond that limit lest the build breaks, which would imply gcc behaves incorrectly. But gcc maintainers reject this notion and believe that a warning switch should never affect code generation, even if it is promoted to an error. One way to unbreak the build is to limit inlining via -finline-limit=100 or by explicitly declaring some functions noinline. However while it does keep stack usage of individual functions below the limit, *total* stack usage increases. A longterm solution is to refactor ecc.c for reduced stack usage. It currently performs ECC point multiplication with a Montgomery ladder which uses co-Z (conjugate) addition to trade off memory for speed. The algorithm is susceptible to timing attacks and needs to be replaced with a constant time Montgomery ladder, which should consume less memory and thus resolve the stack usage issue as a side effect. In the interim, raise the limit for ecc.c, as is already done for several other files in the source tree. Constrain to gcc because clang 19.1.7 does not exhibit the issue. It makes do with a 724 bytes stack frame even though it inlines almost the same functions as gcc. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124949 Reported-by: Andrew Morton # off-list Signed-off-by: Lukas Wunner Acked-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a14e90faff6d6b3e7f073c2aeda430e76510cb98 Author: Kumar Meiyappan Date: Thu Apr 16 15:46:50 2026 +0000 scsi: pm8001: Reject non-fatal dump when controller is crashed [ Upstream commit aa3b8f56ef27ed72394a752820abdec4608b731c ] pm80xx_get_non_fatal_dump() can be called even after the controller has entered a fatal error state. In that case the forensic memory contents are not safe to access for a non-fatal dump request, and attempting to do so can trigger a call trace. Check controller_fatal_error before reading the non-fatal dump buffer and return -EINVAL when the controller is already in a crashed state. This prevents non-fatal dump collection from running in an invalid controller state. Signed-off-by: Kumar Meiyappan Signed-off-by: Sagar Biradar Link: https://patch.msgid.link/20260416154650.415624-1-sagar.biradar@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bbe8e1f2e640da474ffa5ffe2b1bea0b43e190e2 Author: Kumar Meiyappan Date: Thu Apr 16 15:37:57 2026 +0000 scsi: pm8001: Reject firmware update in fatal error state [ Upstream commit 2a8fbcfb04aa9db189bfa3842d4f586aecd0e631 ] pm8001_store_update_fw() allows a firmware update request even when the controller has already entered a fatal error state. Firmware update is not valid once the controller is in that state, and attempting it can lead to a call trace. Reject the request early by checking controller_fatal_error, set the firmware status to FAIL_PARAMETERS, and return -EINVAL. Signed-off-by: Kumar Meiyappan Signed-off-by: Sagar Biradar Link: https://patch.msgid.link/20260416153757.414896-1-sagar.biradar@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c58b93827cf2ee6df6f9c677eff20458e7d0c50a Author: Viacheslav Dubeyko Date: Tue May 5 15:00:52 2026 -0700 hfsplus: rework hfsplus_readdir() logic [ Upstream commit 4b0496432844628ad05a5b1efce329a3340174d2 ] The xfstests' test-case generic/637 fails with error: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ #8 SMP PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Debugging of the hfsplus_readdir() logic showed this: hfsplus: hfsplus_readdir(): 163 ctx->pos 0 hfsplus: hfsplus_readdir(): 189 ctx->pos 1 hfsplus: hfsplus_readdir(): 264 ctx->pos 2, ino 18 hfsplus: hfsplus_readdir(): 264 ctx->pos 3, ino 19 hfsplus: hfsplus_readdir(): 264 ctx->pos 4, ino 28 hfsplus: hfsplus_readdir(): 264 ctx->pos 5, ino 118 hfsplus: hfsplus_readdir(): 264 ctx->pos 6, ino 29 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 30 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 31 hfsplus: hfsplus_readdir(): 304 ctx->pos 8 hfsplus: hfsplus_unlink():420 dir->i_ino 17, inode->i_ino 28 hfsplus: hfsplus_readdir(): 141 ctx->pos 7 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 31 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 32 hfsplus: hfsplus_readdir(): 264 ctx->pos 9, ino 33 It means that hfsplus_readdir() stopped the processing of folder's items on ctx->pos 8, then, item with ino 28 has been deleted and hfsplus_readdir() re-started the logic from ctx->pos 7. As a result, previous and new sets of folder's items have overlapping values for the case of d_off 8. Currently, HFS+ has very complicated and fragile logic of rd->file->f_pos correction in hfsplus_delete_cat(). This patch removes this logic and it stores the current pos into hfsplus_readdir_data. Finally, if rd->pos == ctx->pos then hfsplus_readdir() tries to find the position in b-tree's node by means of hfsplus_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #44 SMP PREEMPT_DYNAMIC Mon May 4 15:58:45 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 22s ... 22s Ran: generic/637 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/198 cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260505220051.2854696-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 620fc44bba2625707045f8509f74eea310415e00 Author: Tom Chung Date: Tue Apr 28 16:41:12 2026 +0800 drm/amd/display: Fix CRC open failure during active rendering [ Upstream commit 5eb2fdafeb6f4a442643b77a21a4c9e70586a146 ] [Why] Opening the CRC data file during active rendering can fail with -EINVAL. The wait for commit->hw_done returns remaining jiffies on success, but the CRC path was treating that as an error. [How] Handle wait_for_completion_interruptible_timeout() correctly: positive return as success, 0 as timeout, and negative as error. Reviewed-by: Ray Wu Signed-off-by: Tom Chung Signed-off-by: James Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 51738de7dd5f8e8b33dfc07ef85bc06d3bf41e96 Author: Stepan Ionichev Date: Thu May 7 00:05:37 2026 +0500 mmc: davinci: avoid NULL deref of host->data in IRQ handler [ Upstream commit 4f28846aaf8db9668e338b8987973f8935edff34 ] mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit "if (data != NULL)" check, but the subsequent TOUTRD ("read data timeout") and CRCWR/CRCRD ("data CRC error") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change. Signed-off-by: Stepan Ionichev Reviewed-by: Bartosz Golaszewski Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 45810fcbdac2cf54643480d796df45859c4e4b42 Author: Ethan Nelson-Moore Date: Sat May 9 22:39:37 2026 -0700 ASoC: ti: omap3pandora: update board check to use DT compatible [ Upstream commit 45efb8fbdae303539e7fb5562e147583d4ed63ad ] The omap3pandora driver contains a check for the ARM machine ID via the machine_is_omap3_pandora() macro. The board concerned now supports only FDT booting, which does not use machine IDs, and therefore the code should be updated to check the DT compatible property instead. The legacy board file for this machine was removed in commit 7fcf7e061edd ("ARM: OMAP2+: Remove legacy booting support for Pandora"). The presence of this machine ID check prevents the removal of machine IDs no longer used by the kernel from arch/arm/tools/mach-types, because the machine_is_*() macros are generated from mach-types. To resolve this issue, use of_machine_is_compatible() instead. Signed-off-by: Ethan Nelson-Moore Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ba769824df4debb8f4f8dfea90d4ef3c7de5e8b3 Author: Geert Uytterhoeven Date: Thu Apr 30 17:20:16 2026 +0200 clk: renesas: cpg-mssr: Add number of clock cells check [ Upstream commit 7f0c422c7fbfd9294ff9321ada0c63561e5c6ea0 ] The number of clock cells is not validated in the clock provider's clk_src_get() callback. Add the missing check. Signed-off-by: Geert Uytterhoeven Reviewed-by: Biju Das Link: https://patch.msgid.link/46e010659ffdffd5e3541369f3b65d43ebe236ec.1777562043.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit c4cf5148660a846f2827dc975d8bfb341479b16d Author: Haoxiang Li Date: Tue Apr 14 16:32:39 2026 +0800 media: em28xx-video: fix missing res_free() on init_usb_xfer failure [ Upstream commit cc20e81da6d99926f94fad7af21f75c07e865769 ] res_get() is called before em28xx_init_usb_xfer(), but the error path of em28xx_init_usb_xfer() does not release the resource, leading to a persistent busy state. Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9516cb2ba79144b8965275eaac27e2825043620c Author: Marek Behún Date: Mon May 4 17:32:26 2026 +0200 net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family [ Upstream commit e0fdb4157a85056bd256a7aebac4a3a2f580b201 ] Commit 9e5baf9b3636 ("net: dsa: mv88e6xxx: add RMU disable op") did not add the .rmu_disable() method for the 6320 family. Add it now. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 34e23c1c259395f7c36f658fae304ae5b7932d65 Author: Marek Behún Date: Mon May 4 17:32:23 2026 +0200 net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family [ Upstream commit d201c2612e5aada0c931cd55115175e0a5141023 ] The 6320 family has 9 global1 interrupt, not 8. Fix it. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260504153227.1390546-2-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2017c80dd7f3c409778ca0898d6e75ccab6d2f2 Author: Zhaoyang Yu <2426767509@qq.com> Date: Wed Apr 15 14:49:09 2026 +0000 media: dm1105: fix missing error check for dma_alloc_coherent [ Upstream commit 3eaac9e02d8591d3c790db572ef1c8fa5a841fdb ] The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure. Signed-off-by: Zhaoyang Yu <2426767509@qq.com> Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d9a638e7bc87e0e6fe3a75517ac481e72fc0058c Author: Mika Westerberg Date: Wed Nov 19 12:49:30 2025 +0200 thunderbolt: Set tb->root_switch to NULL when domain is stopped [ Upstream commit e56249d8a68e712f3b60e1f3fdbb5b4fea146468 ] Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 06b2e894e640f6a3dbeb536a2d26d72426b26a46 Author: Mika Westerberg Date: Fri Nov 21 08:47:23 2025 +0200 thunderbolt: Keep the domain reference while processing hotplug [ Upstream commit 138ec65b2c761f065b19d115aed2b8246fc272f5 ] We process hotplug events in a workqueue that may run after the domain has been removed by tb_domain_remove(). For example if user unloads the driver while at the same time plugging a device router we may have scheduled tb_handle_hotplug() to run. Avoid possible UAF in this case by taking the domain reference before scheduling the hotplug handler in tb_queue_hotplug(). Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit dbc8a8dd7c1930043c473818fcadcf88cb5e1c4d Author: Mika Westerberg Date: Wed Nov 19 13:15:58 2025 +0200 thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() [ Upstream commit 4c63f29872cb444b33665348bbd2f45cab06afcd ] If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit e974262ace03e14eb3bd1998cce38b683bcafdbf Author: Riccardo Boninsegna Date: Sun Mar 29 12:37:09 2026 +0200 media: rc: mceusb: Add support for 04eb:e033 [ Upstream commit 0692c2602e4cd410aa045f8991bd1c142b2e56f9 ] This is a Sonix SN8P2202XG microcontroller with firmware compatible with the already supported Northstar 04eb:e004, implementing an MCE IR receiver (PCB seems to be tracked for a transmitter too but missing related parts). Found in a Skintek SK-CR-IN+IR ( http://www.skintek.it/SK-CR-IN+IR.php ) internal 3.5 inch USB card reader and MCE receiver combo (implemented by, and wired as, separate USB devices) PCB marking: AU6475 966816 STIR REV:A02 MCE Signed-off-by: Riccardo Boninsegna Signed-off-by: Sean Young Signed-off-by: Sasha Levin commit 7a6a614f13ce1ee098d6ac48ab7dda3edcee5f3c Author: Pengpeng Hou Date: Fri Apr 3 14:55:12 2026 +0800 soundwire: validate DT compatible before parsing it [ Upstream commit 45c7bda7b7440183850012153988e40b300f40d0 ] `sdw_of_find_slaves()` fetches raw `"compatible"` bytes with `of_get_property()` and then immediately parses them with `sscanf("sdw%01x%04hx%04hx%02hhx", ...)`. Live-tree OF properties are stored as raw bytes plus a separate length; they are not globally guaranteed to be NUL-terminated. Validate the first compatible string before parsing it. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260403183504.4-soundwire-compatible-pengpeng@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9943c3757ed2bf079e708706188a80d93770e149 Author: Danielle Ratson Date: Wed Apr 29 09:24:04 2026 +0300 bridge: Do not suppress ARP probes and DAD NS unconditionally [ Upstream commit fee1fc1d5a5475f5516d406a03e443348cd0f06c ] When neighbor suppression is enabled on a VXLAN port, the bridge is expected to reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist. This allows the bridge to suppress flooding of these messages to the VXLAN overlay. According to RFC 9161 ("Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks"): "A PE SHOULD reply to broadcast/multicast address resolution messages, i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages. An ARP probe is an ARP Request constructed with an all-zero sender IP address that may be used by hosts for IPv4 Address Conflict Detection as specified in [RFC5227]". However, the current implementation unconditionally suppresses ARP probes and DAD Neighbor Solicitations, which breaks Duplicate Address Detection (DAD) over EVPN. For DAD to work correctly over the VXLAN fabric: - When the bridge does not know the answer: flood the probe/DAD packet to allow remote VTEPs to respond. - When the bridge knows the answer: reply to indicate the address is in use. Fix by adjusting the early suppression checks to exclude ARP probes and DAD NS from unconditional suppression. When replying to a DAD NS, br_nd_send() is adjusted to set the NA destination to the all-nodes multicast address (ff02::1) and clear the Solicited flag, in accordance with RFC 4861 section 7.2.4. Reviewed-by: Ido Schimmel Signed-off-by: Danielle Ratson Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260429062405.1386417-2-danieller@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e8b2e6734479cea73a27b38974601c83a51e0b20 Author: Marco Elver Date: Wed Apr 22 13:59:45 2026 +0200 kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access() [ Upstream commit 07a1a6562ce29e2e0c134a57882d6e52e8758492 ] Some subsystems enable -Wmaybe-uninitialized [1], which can trigger false positives when KCSAN is enabled. Specifically, passing an uninitialized variable to functions that instrument accesses (e.g., copy_from_user()) results in calls to __kcsan_check_access(). Because __kcsan_check_access() takes a `const volatile void *ptr`, GCC infers that the function may only read the memory location, and thus warns if the passed variable is uninitialized. However, KCSAN is a dynamic analysis tool for data race detection; while it does read the memory location to detect concurrent modifications, the "initialized'ness" of the memory location is irrelevant for its analysis. Use absolute_pointer() in __kcsan_check_write(), kcsan_check_write(), and kcsan_check_atomic_write() to hide the pointer from the compiler, preventing it from concluding that the pointer passed points to uninitialized memory. This fixes warnings like: | CC fs/ntfs3/file.o | In file included from include/asm-generic/rwonce.h:27, | from arch/arm64/include/asm/rwonce.h:81, | from include/linux/compiler.h:369, | from include/linux/array_size.h:5, | from include/linux/kernel.h:16, | from include/linux/backing-dev.h:12, | from fs/ntfs3/file.c:10: | In function 'instrument_copy_from_user_before', | inlined from '_inline_copy_from_user' at include/linux/uaccess.h:184:2, | inlined from 'copy_from_user' at include/linux/uaccess.h:221:9, | inlined from 'ntfs_ioctl_fitrim' at fs/ntfs3/file.c:77:6, | inlined from 'ntfs_ioctl' at fs/ntfs3/file.c:164:10: | include/linux/kcsan-checks.h:220:28: error: 'range' may be used uninitialized [-Werror=maybe-uninitialized] | 220 | #define kcsan_check_access __kcsan_check_access | | ^ | include/linux/kcsan-checks.h:311:9: note: in expansion of macro 'kcsan_check_access' | 311 | kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE) | | ^~~~~~~~~~~~~~~~~~ | include/linux/instrumented.h:147:9: note: in expansion of macro 'kcsan_check_write' | 147 | kcsan_check_write(to, n); | | ^~~~~~~~~~~~~~~~~ | include/linux/kcsan-checks.h: In function 'ntfs_ioctl': | include/linux/kcsan-checks.h:37:6: note: by argument 1 of type 'const volatile void *' to '__kcsan_check_access' declared here | 37 | void __kcsan_check_access(const volatile void *ptr, size_t size, int type); | | ^~~~~~~~~~~~~~~~~~~~ | fs/ntfs3/file.c:65:29: note: 'range' declared here | 65 | struct fstrim_range range; | | ^~~~~ Link: https://lore.kernel.org/all/5da10cca-875b-418d-b54e-6be3ea32c266@app.fastmail.com/ [1] Reported-by: Arnd Bergmann Reviewed-by: Arnd Bergmann Tested-by: Arnd Bergmann Signed-off-by: Marco Elver Signed-off-by: Sasha Levin commit 0ccf3b878dc68a289a22cd9a3f8e84fa022f94cd Author: Johannes Berg Date: Fri Apr 17 14:16:01 2026 +0200 wifi: mac80211: always allow transmitting null-data on TXQs [ Upstream commit 51129a2ca0482b006d0e12a0aa025ff1e1cad2cb ] Jouni reported that certain sequences of tests caused some WDS tests to fail after applying the upcoming hwsim changes for NAN. I bisected that down to converting hwsim to TXQs, and after a long debug session found that the 4-addr NDP was getting dropped, because it goes out via a (management) TXQ and is a data frame. It's unclear to me now why this only happens in some test sequences (e.g. "sigma_dut_sae_h2e_ap_loop ap_wds_sta" and "sigma_dut_eap_ttls_all_akm_suites ap_wds_sta_open"), maybe that affects timing and the frame is otherwise delayed in some way. Correct the check to only drop frames that actually carry data, not NDPs. Reported-by: Jouni Malinen Link: https://patch.msgid.link/20260417141601.851ddf4adb59.I3d668c0e1bdca9cd98f2fc46f84a066e68cc7a62@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 985d36d5313791f0eea5df4faa6feaea3f006879 Author: Viacheslav Dubeyko Date: Fri Apr 17 14:49:41 2026 -0700 hfsplus: fix issue of direct writes beyond end-of-file [ Upstream commit 5f63ac80aef2ee6bb58eab62e98c264774872da6 ] The xfstests' test-case generic/729 fails with error: sudo ./check generic/729 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #36 SMP PREEMPT_DYNAMIC Fri Apr 17 12:40:51 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/729 23s ... [failed, exit status 1]- output mismatch mmap-rw-fault: /mnt/test/mmap-rw-fault.tmp: Input/output error The hfsplus_get_block() only allows creating the next sequential block. It returns -EIO for direct writes beyond EOF. This patch waits for any in-flight DIO on the inode to finish. Then, it extends the file by calling generic_cont_expand_simple() with the goal to guarantee that blockdev_direct_IO() finds all needed blocks already reachable sequentially. And, finally, it flushes and invalidates the DIO range again so the page cache is clean before the direct write begins. sudo ./check generic/729 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #40 SMP PREEMPT_DYNAMIC Thu Apr 16 15:41:03 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/729 23s ... 32s Ran: generic/729 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/210 cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260417214940.2735557-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2ac522bbae7a4d95647f5ac0fa34a954dce3dc31 Author: Lukas Wunner Date: Fri Apr 17 10:51:46 2026 +0200 PCI: Stop setting cached power state to 'unknown' on unbind [ Upstream commit d462c8e89e84bfb6417e6b4c88e0cb7cc747ba41 ] When a PCI device is unbound from its driver, pci_device_remove() sets the cached power state in pci_dev->current_state to PCI_UNKNOWN. This was introduced by commit 2449e06a5696 ("PCI: reset pci device state to unknown state for resume") to invalidate the cached power state in case the system is subsequently put to sleep. For bound devices, the cached power state is set to PCI_UNKNOWN in pci_pm_suspend_noirq(), immediately before entering system sleep. Extend to unbound devices for consistency. This obviates the need to change the cached power state on unbind, so stop doing so. Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/af7d11d3ceb231acc90829f7a5c8400c2446744f.1776415510.git.lukas@wunner.de Signed-off-by: Sasha Levin commit c84a1edc503d2e393edb1bbe56aa19e5ba43faf9 Author: Hirokazu Honda Date: Thu Apr 16 15:18:19 2026 -0700 tee: optee: Allow MT_NORMAL_TAGGED shared memory [ Upstream commit 1a6e94a8ff32e7879effd1e4a45bf112e506edc1 ] On ARM64, shared memory can have MT_NORMAL_TAGGED attribute when using the Memory Tagging Extension (MTE). The OP-TEE driver needs to recognize this as normal memory to allow sharing such buffers with the Secure World. Signed-off-by: Hirokazu Honda Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 86acb68ebb220b83def94e7f4c33e24e843970e0 Author: Goldwyn Rodrigues Date: Wed Apr 22 07:34:51 2026 -0400 ima: return error early if file xattr cannot be changed [ Upstream commit 69fc6474236d9edda6983623e4282f2bdfd8e3d8 ] During early boot, the filesystem is read-only and any changes to xattrs are not allowed. This fails in case of ext4 because changing xattr starts an ext4 transaction which fails with the following warning. WARNING: fs/ext4/ext4_jbd2.c:75 at ext4_journal_check_start+0x63/0xa0 [ext4], CPU#1: systemd-sysroot/561 CPU: 1 UID: 0 PID: 561 Comm: systemd-sysroot Not tainted 6.19.12-1-default #1 PREEMPT(voluntary) openSUSE Tumbleweed c2dfc3c9d9f6f1233251c5d4410574fe82a348ee Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:ext4_journal_check_start+0x63/0xa0 [ext4] Call Trace: __ext4_journal_start_sb+0x3e/0x180 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] ext4_xattr_set+0x104/0x150 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] __vfs_setxattr+0x9a/0xd0 __vfs_setxattr_noperm+0x76/0x1f0 ima_appraise_measurement+0x23e/0xe40 ima_d_path+0x5a/0xd0 process_measurement+0xb29/0xc40 ? copy_from_kernel_nofault+0x21/0xe0 ? fscrypt_file_open+0xc0/0xe0 ? ext4_file_open+0x60/0x490 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] ? bpf_prog_31efb7c56239148b_restrict_filesystems+0xab/0x126 ? __bpf_prog_exit+0x23/0xd0 ? __bpf_tramp_exit+0xd/0x50 ? bpf_trampoline_6442530367+0x9f/0xea ima_file_check+0x57/0x80 security_file_post_open+0x50/0xf0 path_openat+0x493/0x1650 do_filp_open+0xc7/0x170 Detect the state of the file early and return the error. Signed-off-by: Goldwyn Rodrigues Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 181012b3d29c51197c235ee5871fc7512c736855 Author: Sven Eckelmann Date: Fri Sep 11 14:48:49 2026 +0200 batman-adv: dat: atomically update mac addresses commit e6de568d3eda3e3c01c868fabd7a9535d5ee4a73 upstream. When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 2f1dfbe18507 ("batman-adv: Distributed ARP Table - implement local storage") [ Context, integrate support for dat_cache debugfs file ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin