commit a500ba24937a966eab140b95eac42782a7ce2c85 Author: Greg Kroah-Hartman Date: Sat Oct 3 12:28:55 2026 +0200 Linux 6.1.189 Link: https://lore.kernel.org/r/20260930152416.775402466@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Brett A C Sheffield Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit b044aa6ae63391ba40c93ca5d476d276cb17db1b Author: Denis Arefev Date: Thu Oct 9 13:50:47 2025 +0300 ALSA: hda: Fix missing pointer check in hda_component_manager_init function commit 1cf11d80db5df805b538c942269e05a65bcaf5bc upstream. The __component_match_add function may assign the 'matchptr' pointer the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced. The call stack leading to the error looks like this: hda_component_manager_init |-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign |-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereference Add IS_ERR() check to prevent the crash. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: ae7abe36e352 ("ALSA: hda/realtek: Add CS35L41 support for Thinkpad laptops") Cc: stable@vger.kernel.org Signed-off-by: Denis Arefev Signed-off-by: Takashi Iwai [Roman: Instead of modifying hda_component_manager_init() (which does not yet exist in version 6.1), a check needs to be added to the cs35l41_generic_fixup() function—the very function introduced by the offending commit, which calls component_match_add() without verifying its successful completion.] Signed-off-by: Roman Demidov Signed-off-by: Greg Kroah-Hartman commit 88d198836f628c57536c6c71d13e90c5d15fbf1a 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 529c07fac37ca422786c946be2f5c0f556cd1369 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 30b386d7a6411028d79404c393e6e7e4533fb082 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 24a8de9d0722201eda1adfc27624c805feb69500 Author: Florian Eckert Date: Mon Dec 4 15:13:35 2023 +0100 tools/thermal/tmon: Fix compilation warning for wrong format commit 9da39ef332c417ce52732564c1c682a6e1209302 upstream. The following warnings are shown during compilation: tui.c: In function 'show_cooling_device': tui.c:216:40: warning: format '%d' expects argument of type 'int', but argument 7 has type 'long unsigned int' [-Wformat=] 216 | "%02d %12.12s%6d %6d", | ~~^ | | | int | %6ld ...... 219 | ptdata.cdi[j].cur_state, | ~~~~~~~~~~~~~~~~~~~~~~~ | | | long unsigned int tui.c:216:44: warning: format '%d' expects argument of type 'int', but argument 8 has type 'long unsigned int' [-Wformat=] 216 | "%02d %12.12s%6d %6d", | ~~^ | | | int | %6ld ...... 220 | ptdata.cdi[j].max_state); | ~~~~~~~~~~~~~~~~~~~~~~~ | | | long unsigned int To fix this, the correct string format must be used for printing. Signed-off-by: Florian Eckert Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20231204141335.2798194-1-fe@dev.tdt.de Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit a6ddaf3b95f211d832d02ffed8d05f77fba4f703 Author: James Clark Date: Mon Jun 23 10:00:12 2025 +0100 perf test: Change all remaining #!/bin/sh to #!/bin/bash commit 2f5d370dec3f800b44bbf7b68875d521e0af43cd upstream. There are 43 instances of posix shell tests and 35 instances of bash. To give us a single consistent language for testing in, replace all #!/bin/sh to #!/bin/bash. Common sources that are included in both different shells will now work as expected. And we no longer have to fix up bashisms that appear to work when someone's system has sh symlinked to bash, but don't work on other systems that have both shells installed. Although we could have chosen sh, it's not backwards compatible so it wouldn't be possible to bulk convert without re-writing the existing bash tests. Choosing bash also gives us some nicer features including 'local' variable definitions and regexes in if statements that are already widely used in the tests. It's not expected that there are any users with only sh available due to the large number of bash tests that exist. Discussed in relation to running shellcheck here: https://lore.kernel.org/linux-perf-users/e3751a74be34bbf3781c4644f518702a7270220b.1749785642.git.collin.funk1@gmail.com/ Signed-off-by: James Clark Reviewed-by: Collin Funk Acked-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250623-james-perf-bash-tests-v1-1-f572f54d4559@linaro.org Signed-off-by: Namhyung Kim When commit b02027776ac5 ("perf tests: Fix flakiness in BPF counters test on hybrid systems") was backported to several stable series (v5.15.221, v6.1.188, v6.6.157, v6.12.110, v6.18.52, v7.2.6) it introduced specific bash syntax. For versions after 2f5d370dec3f ("perf test: Change all remaining #!/bin/sh to #!/bin/bash") in v6.17-rc1 this is not a problem as the shebang was already hanged to #!/bin/bash. For the older stable series this introduced invalid syntax if #!/bin/sh is not bash: $ sh -n tools/perf/tests/shell/stat_bpf_counters.sh tools/perf/tests/shell/stat_bpf_counters.sh: 12: Syntax error: "(" unexpected $ checkbashism tools/perf/tests/shell/stat_bpf_counters.sh possible bashism in tools/perf/tests/shell/stat_bpf_counters.sh line 52 (bash arrays, ${name[0|*|@]}): base_instructions=$(perf stat --no-big-num -e instructions:u -- "${workload[@]}" 2>&1 | \ awk -v i=0 -v c=0 '/instructions/ { \ if ($1 != " 0) printf "%.0f", c; else print "&1 | \ awk -v i=0 -v c=0 '/instructions/ { \ if ($1 != " 0) printf "%.0f", c; else print "&1) Change shebang for the stat_bpf_counters.sh script. No upstream commit exists for this change as for versions post 6.17-rc1 the scripts were converted to #!/bin/bash already. Signed-off-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 7fe391ad14592eff3b5fe2aa30ac9a5438d0fc49 Author: Jakub Kicinski Date: Wed Apr 29 15:29:38 2026 -0700 net: tls: fix silent data drop under pipe back-pressure [ Upstream commit 7e7be31bfdb066c1c780dcd6b1224078fc54063f ] tls_sw_splice_read() uses len when advancing rxm->offset / rxm->full_len after skb_splice_bits(), rather than copied (the actual number of bytes successfully spliced into the pipe). When the destination pipe cannot accept all the requested bytes, splice_to_pipe() returns fewer bytes than len, and 'len - copied' of data is effectively skipped over. Fixes: e062fe99cccd ("tls: splice_read: fix accessing pre-processed records") Link: https://patch.msgid.link/20260429222944.2139041-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fdfbc1e77907854a13e9d6f870f3f43eb93e3461 Author: Darrick J. Wong Date: Mon Sep 14 22:38:23 2026 -0700 xfs: fix blockgc group quota scanning when usrquota isn't enforced commit f8f6382ff13109e19d0fc1d0224ff7d29641e56a upstream. LOLLM noticed the copy-paste error here -- if user quotas aren't enforced but we're near the group quota limit, we fail to set FLAG_GID and hence we might not actually free any preallocations, causing unnecessary EDQUOT. Fix that. Cc: stable@vger.kernel.org # v5.12 Fixes: c237dd7c709432 ("xfs: flush eof/cowblocks if we can't reserve quota for inode creation") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 47b18b752c4d398d94ce22643993baf407a24879 Author: Zihan Xi Date: Wed Sep 16 15:29:25 2026 +0000 smb: client: validate POSIX create context length commit fa2e9900dd2a3f5a1e7ef5a8c5e8d435feedbfcc upstream. parse_posix_ctxt() reads the fixed nlink, reparse_tag, and mode fields before checking that the POSIX create context contains them. A short context can pass the generic checks and still make these fixed-width reads run past its declared data. The current in-tree smb2_open_file() path passes a NULL posix pointer, so this handler is not reached on the ordinary open path. Still require the POSIX data to cover all three fields before reading them because the helper performs those unguarded reads. Keep the existing soft-failure behavior so malformed optional metadata does not fail the open. Fixes: 69dda3059e7a ("cifs: add SMB2_open() arg to return POSIX data") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 1c4f7e1177da2f229be04139c27e5370a1cfba52 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 3acf6a0038ec0d4e8f4dcbfc2a557dff5f61cb70 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 c1fd465ea1c5aef459f9bc3ac602b5353e0f536f 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 2501a3b7b7144d1d11939b355a48ed01f83d0c62 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 9bdbae64ae0dab93041ebc57ec4e93def793fc2d Author: Myeonghun Pak Date: Sat Aug 1 01:35:50 2026 +0900 RISC-V: KVM: Synchronize hrtimer callback during teardown commit aaad136d56d91252517272b68cd533e5714698d5 upstream. The non-Sstc hrtimer callback clears next_set before its final uses of the enclosing vCPU. If teardown observes next_set as false while the callback is still running, kvm_riscv_vcpu_timer_cancel() skips hrtimer_cancel() and kvm_destroy_vcpus() can free the vCPU before the callback enters kvm_riscv_vcpu_set_interrupt(). A guest can arm the timer with SBI TIME and request shutdown with SBI legacy shutdown or SRST. A VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM supplies the teardown side of the race; no post-launch host ioctl is needed to arm or request teardown. On upstream master 62cc90241548, generic KASAN reported: BUG: KASAN: slab-use-after-free in do_raw_spin_lock Write of size 4 at addr ff60000005e58898 kvm_riscv_vcpu_set_interrupt kvm_riscv_vcpu_hrtimer_expired __hrtimer_run_queues hrtimer_interrupt The object was allocated by KVM_CREATE_VCPU and freed concurrently by: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput For deterministic validation, I added mdelay(1000) immediately after the existing next_set = false assignment. This only widens the existing post-clear callback window. A no-delay trace build naturally reached the callback-after-teardown-start/before-deinit ordering in 12 of 200 runs, but 1,500 stock-kernel stress iterations did not produce a KASAN report, so natural reproduction is timing-sensitive. Always invoke hrtimer_cancel() for an initialized timer. Preserve the existing -EINVAL result when the timer is no longer set, but only after synchronizing with a running callback. With this patch, hrtimer_cancel() blocked for the full widened callback window before vCPU destruction. KASAN reported no error in 100 fixed-and-widened runs or 200 fix-only timing-sweep runs. Fixes: 3a9f66cb25e1 ("RISC-V: KVM: Add timer functionality") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Myeonghun Pak Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260731163550.46991-1-mhun512@gmail.com Signed-off-by: Anup Patel Signed-off-by: Greg Kroah-Hartman commit 27e396a89f76f742abdbe9f8c4a58a6e806fdf59 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 7ab0f04113fb1328405fa81d2f418caf1708e75a 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 94e5bdd08e51c450d954bc592f591c233ca5c9df 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 db66a30588630c7de30ef033f00daddef69f6ad9 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 51b6d73373589abb9de4d84767b0db1bc8d395d9 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 c40f61a6a413f3eaf028e5fe367fd9749e503ab0 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 5a54f8b7f7fe207a5c14713015a5820588faf1ad 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 65487e9e99431ffcf05024a817f51ee4e3bd9b47 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 bbeb41644e961af07a2adc8133779fbfc6762233 Author: Wentao Liang Date: Thu Sep 17 11:58:11 2026 +0000 net: usb: lan78xx: Fix URB reference leak in lan78xx_submit_deferred_urbs() commit 17741334d00bf5ebd37f8c1c36bc9c146a351deb upstream. usb_get_from_anchor() hands over a reference to the URB, which the caller must release. lan78xx_submit_deferred_urbs() never does, so every deferred Tx URB keeps an extra reference: the counter grows on each suspend/resume cycle and the URBs are never freed when the buffers are released. Drop the reference after submitting, and on the path that drops the packet instead of submitting it. Fixes: 5f4cc6e25148 ("lan78xx: Fix race conditions in suspend/resume handling") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917115811.2150119-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 9476bf8d80a376b045462315f5c9435ececb3e3b 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 34bc747a61bef572244b01b095552b629cd8d2a2 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 4daf80da0c38b8cd92c111ad96cb38322aabf586 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 707c2dc77891a874f4e8c52c285a511079164ec8 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 d8cebce564d8786d4fa7fccfe40ec019dd10b95c 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 6ab9f61ca851f02ae4398cebaf00735a22e1d6ca 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 7389757d88f54237951d7497d9c4dae7cc6d64be 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 6bf076258aac4e0af69ef317656c31ce6444d647 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 c45c997d0c27359b502587897f775c5a277f0bd4 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 456afe4707e23cc114ad833197f63b52bb8fd1e7 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 701aad3e1318858c6193f0b46f351a728c690357 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 ef8ca5bb4c8b9696f38b1bebce1c851baa02b77b 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 5cb7109f0f5f1b47b172e2d5b868d4ce3ae687f8 Author: Peiyang He Date: Fri Sep 18 10:53:12 2026 +0800 drm/nouveau: don't bump pin count on failed re-pin in nouveau_bo_pin_locked() commit 6a6870d3077faa501ca97760057ddca22b68418d upstream. nouveau_bo_pin_locked() checks whether an already pinned BO is in a memory domain compatible with a new pin request. When the domains are incompatible, it sets -EBUSY but still calls ttm_bo_pin() before returning. Callers treat a failed nouveau_bo_pin() as not having acquired a new pin, so the extra pin count is never decreased by a matching unpin. This triggers the warning in ttm_bo_release(): WARN_ON_ONCE(bo->pin_count); Found when fuzzing the nouveau driver with a modified Syzkaller: WARNING: drivers/gpu/drm/ttm/ttm_bo.c:256 at ttm_bo_release+0x827/0x9e0 drivers/gpu/drm/ttm/ttm_bo.c:256, CPU#1: syz.3.24/2212 Modules linked in: CPU: 1 UID: 0 PID: 2212 Comm: syz.3.24 Not tainted 7.2.0 #24 PREEMPT(lazy) nouveau 0000:01:00.0: gsp:msg fn:103 len:0x40/0x20 res:0x19 resp:0x19 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ttm_bo_release+0x827/0x9e0 drivers/gpu/drm/ttm/ttm_bo.c:256 Code: 02 00 0f 85 51 01 00 00 48 8b 7b 08 e8 d2 20 01 00 e9 80 fd ff ff e8 d8 15 c0 fe 90 0f 0b 90 e9 e1 f8 ff ff e8 ca 15 c0 fe 90 <0f> 0b 90 e9 a4 f8 ff ff e8 bc 15 c0 fe be 03 00 00 00 4c 89 e7 e8 msg: 00000000: 05 00 d0 c1 04 00 f0 f1 01 30 00 00 2d 90 00 00 .........0..-... RSP: 0018:ffffc9000f5cf710 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888018e5d2a8 RCX: ffffffff82bb1b36 RDX: ffff888017b68000 RSI: 0000000000000004 RDI: ffff888018e5d2a8 msg: 00000010: 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ RBP: ffff88801261c720 R08: 0000000000000001 R09: ffffed10031cba55 R10: ffff888018e5d2ab R11: 00000000000000f3 R12: ffff888018e5d290 R13: ffff888018e5d2d4 R14: ffff88801b219c18 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880e0f6f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31223ffc CR3: 0000000028e00005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: kref_put include/linux/kref.h:65 [inline] ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:325 [inline] ttm_bo_fini+0x55/0x80 drivers/gpu/drm/ttm/ttm_bo.c:330 nouveau_gem_object_del+0xb2/0x1b0 drivers/gpu/drm/nouveau/nouveau_gem.c:90 drm_gem_object_free+0x5f/0x90 drivers/gpu/drm/drm_gem.c:1165 kref_put include/linux/kref.h:65 [inline] __drm_gem_object_put include/drm/drm_gem.h:562 [inline] drm_gem_object_put include/drm/drm_gem.h:575 [inline] nouveau_abi16_chan_fini.constprop.0+0x44f/0x5a0 drivers/gpu/drm/nouveau/nouveau_abi16.c:195 nouveau 0000:01:00.0: syz.2.23[2209]: Unknown handle 0x00000000 nouveau_abi16_fini+0x1d0/0x340 drivers/gpu/drm/nouveau/nouveau_abi16.c:225 nouveau_drm_postclose+0x18b/0x3e0 drivers/gpu/drm/nouveau/nouveau_drm.c:1284 nouveau 0000:01:00.0: syz.2.23[2209]: validate_init drm_file_free.part.0+0x6d6/0xb60 drivers/gpu/drm/drm_file.c:267 drm_file_free drivers/gpu/drm/drm_file.c:237 [inline] drm_close_helper.isra.0+0x11a/0x160 drivers/gpu/drm/drm_file.c:290 drm_release+0x1ab/0x330 drivers/gpu/drm/drm_file.c:438 __fput+0x39c/0xa60 fs/file_table.c:512 nouveau 0000:01:00.0: syz.2.23[2209]: validate: -2 task_work_run+0x15a/0x230 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x82b/0x25a0 kernel/exit.c:1009 do_group_exit+0xc2/0x280 kernel/exit.c:1152 get_signal+0x1d6e/0x1f30 kernel/signal.c:3046 arch_do_signal_or_restart+0x7d/0x6e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:66 [inline] exit_to_user_mode_loop+0xdf/0x440 kernel/entry/common.c:101 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline] do_syscall_64+0x4f8/0x690 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f12bac8594d Code: Unable to access opcode bytes at 0x7f12bac85923. RSP: 002b:00007f12b96e70d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: 0000000000000001 RBX: 00007f12baf15fa8 RCX: 00007f12bac8594d RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 00007f12baf15fac RBP: 00007f12baf15fa0 R08: 00007f12baee8000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f12baf16038 R14: 0000000000000006 R15: 00007ffe2ed394b0 irq event stamp: 47867 hardirqs last enabled at (47883): [] __up_console_sem+0x66/0x70 kernel/printk/printk.c:347 hardirqs last disabled at (47892): [] __up_console_sem+0x4b/0x70 kernel/printk/printk.c:345 softirqs last enabled at (47880): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last enabled at (47880): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last enabled at (47880): [] __irq_exit_rcu+0x137/0x1c0 kernel/softirq.c:735 softirqs last disabled at (47875): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last disabled at (47875): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last disabled at (47875): [] __irq_exit_rcu+0x137/0x1c0 kernel/softirq.c:735 Fix by calling ttm_bo_pin() only when the existing placement is compatible with the new pin request. This matches the correct behavior in other DRM drivers such as amdgpu_bo_pin() in amdgpu. Cc: stable@vger.kernel.org Fixes: ad76b3f7c7a0 ("drm/nouveau: teach nouveau_bo_pin() how to force a contig vram allocation") Signed-off-by: Peiyang He Assisted-by: LLM Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/EACEF2F4E098413F+20260918025312.2814889-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 957619120c26d6727efd18504e6b488673d3900a 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 bf542ecd4f60d4689818d194e7ca74772fe0f8b5 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 9ffb43369ae51af5d5646b1ef680ab1af0fb4ad9 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 63e87b582ba105fc59d14ba0beb32e000b29be4e 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 f55863589b106a3b10183fa233cdf782b51b5682 Author: Wentao Liang Date: Wed Sep 16 10:01:39 2026 +0000 drm/amdgpu: Fix vmid_wait fence leak in amdgpu_ring_init() commit aea841bc62a76242396610d22d8ff40c13065f64 upstream. amdgpu_ring_init() initializes ring->vmid_wait with a reference to the stub fence taken via dma_fence_get_stub(). When a later step of the initialization fails, e.g. amdgpu_fence_driver_init_ring(), a writeback slot allocation or the ring buffer allocation, the function returns an error without releasing the stub fence reference and the reference is leaked if the ring is torn down without amdgpu_ring_fini(). Move the stub fence assignment to the end of the initialization, right before the ring is registered with the GPU scheduler, where no further failure is possible. The stub fence is only consumed by command submission handling in amdgpu_ids.c once the ring is up and running, so nothing reads it during the error-prone part of the initialization. Fixes: 48e9fbd1a284 ("drm/amdgpu: initialize the vmid_wait with the stub fence") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit f2b96986851203e9c50ca0d13aaa3581ca3e8ebd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fc5606ac91642d0f184b83ab833148c457c3c331 Author: Wentao Liang Date: Wed Sep 16 09:58:05 2026 +0000 drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show() commit 2b86ab1bd6673c525adda88819d7658ba9e784ec upstream. amdgpu_debugfs_test_ib_show() resumes the device with pm_runtime_get_sync() before taking the reset domain semaphore with down_write_killable(). If the write lock acquisition is interrupted, the function returns without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference acquired for the device and keeping the GPU awake. Drop the runtime PM reference on the interrupted down_write_killable() error path before returning. Fixes: 6049db43d6dd ("drm/amdgpu: change reset lock from mutex to rw_semaphore") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit ec30a576c2d4c0364549e6c04218f50704ef56c8) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 99d4f914d419bb98aad5fed43df7b7181ebcb950 Author: Wentao Liang Date: Wed Sep 16 09:55:36 2026 +0000 drm/amdgpu: Fix last_update fence leak in amdgpu_vm_init() commit b4f7b4459b1b155e4c4977a6482b5df2cf08758c upstream. amdgpu_vm_init() initializes vm->last_update, vm->last_unlocked and vm->last_tlb_flush with references to the stub fence taken via dma_fence_get_stub(). The error label at the end of the function releases the last_unlocked and last_tlb_flush references with dma_fence_put(), but the reference stored in vm->last_update is never dropped, so whenever the page table root creation, the reservation of the root BO or the PASID registration fails, the stub fence reference leaks. Drop the vm->last_update reference together with the other stub fence references on the error path. Fixes: 187916e6ed9d ("drm/amdgpu: install stub fence into potential unused fence pointers") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit e7979c84fc05a176bdf855ee664871b1648404c9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4d4ca84213327da1f84ef7af3946dea6b14c5d88 Author: Christian König Date: Thu Sep 3 13:36:21 2026 +0200 drm/i915: fix incorrect RCU teardown order commit d2da6696e0c4e60414706e607029d0bb0330c67e upstream. i915_gem_busy_ioctl uses dma_resv_for_each_fence_unlocked() to iterate over the fences in an GEM object without holding a reference but only the RCU read side lock. What can happen here is that the GEM object is destroyed concurrently while i915_gem_busy_ioctl is still running. This won't free the GEM objects memory, but still drops all the dma_fence references. Now when dma_resv_for_each_fence_unlocked() sees a destroyed dma_fence it assumes that a new fence list was installed and re-starts the loop. But in the case of a destroyed GEM object a new fence list is never installed, only the old one freed and therefore the iteration never finishes resulting in an endless loop. The solution is to drop the fence references only after the RCU grace period. The fixes tag is not necessary the patch introducing the problem, but the one making it so worse that we need to address it. This problem was pointed out by Sashiko-bot. Signed-off-by: Christian König Fixes: 912ff2ebd695 ("drm/i915: use the new iterator in i915_gem_busy_ioctl v2") CC: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260903113621.54660-1-christian.koenig@amd.com (cherry picked from commit 5113479556025093bf8133bb2dcaa33be2d50921) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 8dca3c81344532a7f05edb3d12f31f3009410a90 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 7c38524b2b2456bd33cb360420da6cbf9cad1b33 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 60a76cdd92e25f576dc58d756a565760dde1f7a1 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 5c8e87f33b68557a725e72f34051299f55c6fa9e 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 e3ac68c1cdc2535d127b2bfd50c263d16c8e4199 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 543354c6efb27eae3372a3a9674aeaa2a86e2b2c 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 5c90f99ba74b55ddd8e919224921033cc4077f01 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 42462b5bb0dec57db7f85d0f77655c737d45754d Author: Josef Bacik Date: Wed Sep 9 18:01:07 2026 +0000 writeback: report a Tasks-RCU quiescent state per cgwb drain pass commit 407a5d205179a4ab186571b0e16ec42725dc77bc upstream. cleanup_offline_cgwbs_workfn() drains a dying cgwb by calling cleanup_offline_cgwb() until it returns false, with a cond_resched() between passes. On a CONFIG_PREEMPTION kernel that cond_resched() does nothing: _cond_resched() is a plain "return 0", and under PREEMPT_DYNAMIC the full and lazy modes disable it. Since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") those are the only two models on the architectures with PREEMPT_LAZY support, arm64 and x86 among them, so the drain loop never reports a Tasks-RCU quiescent state. A worker draining a cgwb with millions of attached inodes runs for minutes. On a 6.18 arm64 host in lazy mode the cgwb worker drained one dying cgroup's writeback domain for over 11 minutes. A BPF program unlink (bpf_trampoline_unlink_prog -> bpf_trampoline_update -> unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks()) waited on that grace period while holding the trampoline mutex, 42 tasks queued behind it in D state, and the hung task detector fired at 614 s and panicked the host. Any BPF or ftrace detach during a long drain inherits the drain's length. Fix this by calling cond_resched_tasks_rcu_qs() so we do not stall out anybody who calls sycnrhonize_rcu_tasks(). We put this in a do { } while loop because if we have many small cgroups cleanup_offline_cgwb() will return false and we will never call cond_resched_tasks_rcu_qs(), creating the same problem. Link: https://lore.kernel.org/20260909-cgwb-tasks-rcu-qs-v1-1-967a7754771f@toxicpanda.com Fixes: c22d70a162d3 ("writeback, cgroup: release dying cgwbs by switching attached inodes") Signed-off-by: Josef Bacik Signed-off-by: Andrew Morton Link: https://lore.kernel.org/bpf/9d444098-7c03-4163-af12-bd0a79a51443@paulmck-laptop/ Assisted-by: LLM Acked-by: Tejun Heo Reviewed-by: Roman Gushchin Reviewed-by: Jan Kara Acked-by: Lorenzo Stoakes (ARM) Cc: David Hildenbrand Cc: Dennis Zhou Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: "Paul E . McKenney" Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Greg Kroah-Hartman commit cc190a6a1d20b87e6a9435202fc2a3bd84c79fb3 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 2d1da58c79b66646721a644c6eb4dd1f9c5c9327 Author: Patrick Lu (Anthropic) Date: Fri Sep 11 18:49:49 2026 +0000 writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes commit f6988c90671e83db79df1b7b9d6fdb0e5947fd84 upstream. cleanup_offline_cgwb() prepares at most WB_MAX_INODES_PER_ISW inodes per call and is called again until the dying wb is drained, but every call walks wb->b_attached and then wb->b_dirty_time from the same end. Inodes already prepared (they stay on the list with I_WB_SWITCH set until the switch worker runs) and inodes that cannot be switched (I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, already on the target wb) stay where they are, so each pass rescans a growing run of them under wb->list_lock and a full drain is quadratic in the number of inodes on the list. With ~17M inodes attached to one dying cgwb we saw this end in soft lockups, with CPUs reported stuck for 21-48s. Walk both lists from the oldest end and move every scanned inode to the newest end, so the next pass starts where the previous one stopped and the drain becomes linear. b_attached is unordered, so nobody sees the reorder there. b_dirty_time is ordered by dirtied_when, but the oldest unscanned inode stays at the end move_expired_inodes() picks from, sync takes the whole list regardless of order, and prepared inodes leave the list as soon as the switch work runs and get a new dirtied_time_when on the new wb anyway, so the only inodes left out of order are the ones that can never switch (DAX), and only on the dying wb. Fixes: c22d70a162d3 ("writeback, cgroup: release dying cgwbs by switching attached inodes") Cc: stable@vger.kernel.org Acked-by: Tejun Heo Acked-by: Roman Gushchin Signed-off-by: Patrick Lu (Anthropic) Link: https://patch.msgid.link/20260911-wb-cgwb-rotate-v2-1-a9ab253a1295@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 7f4ba56f5d310dd018972916167985010a5d66a1 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 297acc571d5813db76b147c745b91031d5f9c960 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 965e21ea16acb394d5e5801998ca9b0adc669665 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 507a27435b2bb1f22e3a3674f6a6553eb815021b 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 826cc35cb65c600e626a53ea8674e3b85b10f0f9 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 7c2fe308bda5a7e6222d7f0c3c311991372baab4 Author: Guanglei Zhu Date: Mon Sep 28 10:04:18 2026 +0800 net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb() commit c7ead9704249d57d4693a04697e3bbd285138fa9 upstream. The netif index carried in the DPMAIF PIT header is five bits wide, but ccmni_inst[] only has room for NIC_DEV_MAX (21) entries. t7xx_ccmni_recv_skb() indexes the array without a bounds check, so indexes 21 to 31 read past it. The out-of-bounds value lands in the callback table that follows the array, which is never NULL, so the existing !ccmni check does not catch it and the driver dereferences whatever sits there as a struct t7xx_ccmni. Drop the skb when the index is out of range. Fixes: 05d19bf500f8 ("net: wwan: t7xx: Add WWAN network interface") Cc: stable@vger.kernel.org Signed-off-by: Guanglei Zhu Link: https://patch.msgid.link/20260911021734.1396599-3-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 866e69a824b46e682b8fb923be321b585e634874 Author: Kuniyuki Iwashima Date: Mon Sep 28 10:55:11 2026 +0000 af_unix: Drop all SCM attributes for SOCKMAP. [ Upstream commit 965dc93481d1b80d341bdd16c27b16fe197175ee ] SOCKMAP can hide inflight fd from AF_UNIX GC. When a socket in SOCKMAP receives skb with inflight fd, sk_psock_verdict_data_ready() looks up the mapped socket and enqueue skb to its psock->ingress_skb. Since neither the old nor the new GC can inspect the psock queue, the hidden skb leaks the inflight sockets. Note that this cannot be detected via kmemleak because inflight sockets are linked to a global list. In addition, SOCKMAP redirect breaks the Tarjan-based GC's assumption that unix_edge.successor is always alive, which is no longer true once skb is redirected, resulting in use-after-free below. [0] Moreover, SOCKMAP does not call scm_stat_del() properly, so unix_show_fdinfo() could report an incorrect fd count. sk_msg_recvmsg() does not support any SCM attributes in the first place. Let's drop all SCM attributes before passing skb to the SOCKMAP layer. [0]: BUG: KASAN: slab-use-after-free in unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) Read of size 8 at addr ffff888125362670 by task kworker/56:1/496 CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: events sk_psock_backlog Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379) kasan_report (mm/kasan/report.c:597) unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) unix_destroy_fpl (net/unix/garbage.c:317) unix_destruct_scm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/af_unix.c:1976) sk_psock_backlog (./include/linux/skbuff.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Allocated by task 955: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) __kasan_slab_alloc (mm/kasan/common.c:369) kmem_cache_alloc_noprof (mm/slub.c:4539) sk_prot_alloc (net/core/sock.c:2240) sk_alloc (net/core/sock.c:2301) unix_create1 (net/unix/af_unix.c:1099) unix_create (net/unix/af_unix.c:1169) __sock_create (net/socket.c:1606) __sys_socketpair (net/socket.c:1811) __x64_sys_socketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860) do_syscall_64 (arch/x86/entry/syscall_64.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 496: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kmem_cache_free (mm/slub.c:6165) __sk_destruct (net/core/sock.c:2282 net/core/sock.c:2384) sk_psock_destroy (./include/net/sock.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Fixes: 77462de14a43 ("af_unix: Add read_sock for stream socket types") Reported-by: Xingyu Jin Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260415184830.3988432-1-kuniyu@google.com Signed-off-by: Jakub Kicinski [Lee: Drop skb_orphan() from unix_destruct_scm() and omit the unix_stream_read_skb() / unix_dgram_read_skb() hunks as 69bbe2bcbe8c and d92fbaccd09a are not present] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5593c640f9daedec8de61555c41e1019fa675aa6 Author: Pablo Neira Ayuso Date: Mon Sep 28 10:05:20 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 24df7b0ce77e1a492a909f62f69728e3e94857bf Author: Pablo Neira Ayuso Date: Mon Sep 28 10:05:19 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 edc3f2b9b26469cf9ed4482485f251ef268529bd Author: Mark Amirkan Date: Sun Sep 13 10:30:05 2026 +0000 mptcp: return sk_wait_data() errors from recvmsg() [ Upstream commit 60404266ef3e0a1cd8f7a164060e0c83efb72f4b ] Commit 581302298524 ("mptcp: error out earlier on disconnect") made mptcp_recvmsg() stop when sk_wait_data() returns an error. The error is stored in err, but the function then jumps to a path which returns copied. When no data was copied, recvmsg() therefore returns zero and reports a false EOF. Store the result in copied, which is the value returned by the function. This also keeps the usual partial-read result when data was copied before the error. A recvmsg() blocked in one thread reproduces the issue when another thread disconnects the same MPTCP socket with connect(AF_UNSPEC). Before this change recvmsg() returns zero; afterwards it returns -EPIPE. Fixes: 581302298524 ("mptcp: error out earlier on disconnect") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260913-b4-send-mptcp-recv-error-v1-1-4eaa3684a8b8@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 386b664bf66ab71d46ecd3cc28f24c7cb31548db Author: Sean Christopherson Date: Mon Sep 21 12:14:10 2026 -0700 perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has PEBS isolation, to fix stuck PEBS_ENABLED [ Upstream commit 4b64dbdc5861477f148e13d1ed127e7fe7182e4f ] When filling the list of MSRs to be loaded by KVM on VM-Enter and VM-Exit, *never* insert an entry for PEBS_ENABLED if the CPU properly isolates PEBS events, in which case disabling counters via PERF_GLOBAL_CTRL is sufficient to prevent unwanted PEBS events in the guest (or host). Because perf loads PEBS_ENABLE with the unfiltered cpu_hw_events.pebs_enabled, i.e. with both host and guest masks, there is no need to load different values for the guest versus host, perf+KVM can and should simply control which counters are enabled/disabled via PERF_GLOBAL_CTRL. Avoiding touching PEBS_ENABLED "fixes" a bug where PEBS_ENABLED can end up with "stuck" bits if a PEBS event is throttled between generating the list and actually entering the guest (Intel CPUs can't arbtitrarily block NMIs). Fixes in quotes because leaving PEBS_ENABLED as-is doesn't fix the underlying problem of perf (via PMIs) being able to modify state after the perf<=>KVM handoff. But not writing PEBS_ENABLED is desirable no matter what, as stating the obvious, leaving PEBS_ENABLED as-is avoids three MSR writes on every VMX transition: one each on entry/exit, and one more explicit WRMSR to zero PEBS_ENABLED before VM-Entry (KVM assumes the only reason PEBS_ENABLED is in the load list is if the CPU lacks PEBS isolation and thus needs a quiescent period). Opportunistically add comments to (better) explain the rules for generating the set of PEBS counters that will be active while the guest is running, along with a FIXME for the suspected hack-a-fix where perf disables guest PEBS if _any_ PEBS event is configured to count in the host (commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") doesn't explain the motivation, at all). Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260921191418.950933-3-seanjc@google.com Signed-off-by: Sasha Levin commit b203e4afce1527c24466ced4e507380a49742af6 Author: Sean Christopherson Date: Mon Sep 21 12:14:09 2026 -0700 perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted PERF_GLOBAL_CTRL bits [ Upstream commit cec38d5c098a350dcf084d345025136ade7e6d1e ] When reinstating PEBS counters into PERF_GLOBAL_CTRL for a KVM guest, mask the value with perf's desired/original PERF_GLOBAL_CTRL value to ensure KVM doesn't unintentionally set reserved bits in PERF_GLOBAL_CTRL. E.g. if the guest's PEBS_ENABLE value had bit 63, "Enable Precise Store", set, then using the raw guest PEBS value would propagate bit 63 to the guest's PERF_GLOBAL_CTRL value (which thankfully would be a failed VM-Entry, not a VMX Abort). The only reason this bug isn't reachable is because KVM doesn't support "Enable Precise Store" (which is probably a KVM bug?), i.e. bit 63 can't be set in kvm_pmu->pebs_enable and thus not in arr[pebs_enable].guest. In other words, this _should_ be a glorified NOP in the current code base. Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260921191418.950933-2-seanjc@google.com Signed-off-by: Sasha Levin commit 34fa4c1c6e10507dc60e35a82cc9655666946cfd 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 4ba1f57313f36a3ce6f77d593548f0c511f34aa1 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 f1209bdad9d4f8b28fa699e8e6d6df01ef4a3b01 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 4fea9c8f6a34d3e4a3a4b6acaa5bd46e9219c2d3 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 8b855b645841b5a04e20339a22bb6d593c9b790d 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 18b7f1f2a57dde7bea7a8e5fa5295375befbd864 Author: Coia Prant Date: Wed Sep 23 20:37:13 2026 +0800 net: ethernet: stmmac: dwmac-rk: fix bulk clock leak when the PHY clock fails [ Upstream commit 8db67bb6a1fffa4df68fbbc22e39943aeeff9178 ] gmac_clk_enable() enables the bulk clocks first and then the optional PHY clock. If clk_prepare_enable() on the PHY clock fails, the function returns without rolling back the bulk clocks, and bsp_priv->clk_enabled stays false, so the later gmac_clk_enable(bsp_priv, false) becomes a no-op and the bulk clock references are leaked. Add the missing clk_bulk_disable_unprepare() on that failure path. Fixes: ea449f7fa0bf ("net: ethernet: stmmac: dwmac-rk: rework optional clock handling") Reviewed-by: Maxime Chevallier Reviewed-by: Heiko Stuebner Acked-by: Lorenzo Bianconi Signed-off-by: Coia Prant Link: https://patch.msgid.link/20260923123713.3137146-1-coiaprant@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70f2e2b5c3876f6e2cf0062fb29c8b97858c7c36 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 0edcc4284392b28826b5d37532b366b291e6e0fa Author: Sidraya Jayagond Date: Tue Sep 22 09:31:49 2026 +0200 net/smc: fix UAF on lgr list traversal in smcr_port_err() [ Upstream commit 61cb282fe97b3b0ba32ca09417a693162bf4ae3f ] smcr_port_err() traverses smc_lgr_list.list without holding smc_lgr_list.lock, allowing a concurrent smc_lgr_terminate_sched() to free an lgr while it is still being dereferenced. Hold smc_lgr_list.lock across the traversal. Update smc_ib_gid_check() to call smcr_port_err() after releasing the lock. Fixes: 541afa10c126 ("net/smc: add smcr_port_err() and smcr_link_down() processing") Reviewed-by: Mahanta Jambigi Signed-off-by: Sidraya Jayagond Reviewed-by: Dust Li Link: https://patch.msgid.link/20260922073149.474762-1-sidraya@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5b4da1f403a658c1c19766be2b426003ada419f Author: Yilin Zhang Date: Thu Sep 24 12:49:00 2026 +0800 tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack() [ Upstream commit fe99bbeee5c5dbd3abc30721a8079ced59649d97 ] When tcp_send_synack() replaces the cloned SYN skb at the head of the retransmit queue with a copy, it frees the original with tcp_rtx_queue_unlink_and_free() and only repairs tp->highest_sack. tp->retransmit_skb_hint keeps pointing at the freed skbuff_fclone_cache object. The dangling hint is read in tcp_verify_retransmit_hint() and used as the root of the rbtree walk in tcp_xmit_retransmit_queue(). An unprivileged TFO client (sendmsg(MSG_FASTOPEN)) can arm the hint with an attacker-supplied ICMP fragmentation-needed message, after which a simultaneous open frees the armed SYN skb: BUG: KASAN: slab-use-after-free in tcp_mark_skb_lost (net/ipv4/tcp_input.c:1316) Read of size 4 at addr ffff88800604d928 by task swapper/1/0 Call Trace: tcp_mark_skb_lost (net/ipv4/tcp_input.c:1316) tcp_simple_retransmit (net/ipv4/tcp_input.c:3158) tcp_v4_err (net/ipv4/tcp_ipv4.c:587) Sync the hint to the copy. Fixes: c31b70c9968f ("tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit") Reported-by: Kimi Security Team Tested-by: Weiming Shi Signed-off-by: Yilin Zhang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/8a9dff4063a2745653b7e88ceb745d75efa16e68.1790224474.git.yilinzhang@moonshot.ai Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6ea8f643053f33622f9116e4e1db58306ece45e3 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 1dc759571f3df14891175fc52527f7624ba01322 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 32a1de0a7f22eb30e6f3bd1fb94677bb94eb29f5 Author: Florian Fainelli Date: Mon Sep 21 15:00:21 2026 -0700 net: bcmgenet: mask DMA_TIMEOUT_MASK when reading DMA_RING0_TIMEOUT [ Upstream commit d64e277b955be4506931802837499b62c8f3968a ] bcmgenet_get_coalesce() reads DMA_RING0_TIMEOUT to calculate rx_coalesce_usecs without masking out bits outside DMA_TIMEOUT_MASK (16 bits). If upper bits are non-zero or contain status/flags, the computed value of rx_coalesce_usecs returned to userspace via ethtool becomes corrupted. Mask the register read with DMA_TIMEOUT_MASK before computing the timeout in microseconds. Fixes: 4a29645bfe6c ("net: bcmgenet: Implement RX coalescing control knobs") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-6-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4f0a176a67659c13f27b58da151bd64c5949d9bf Author: Florian Fainelli Date: Mon Sep 21 15:00:20 2026 -0700 net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr [ Upstream commit 273941c85fc2632cd3e56ddff737b9245de7697d ] bcmgenet_set_mac_addr() did not check whether the provided MAC address is a valid Ethernet address before applying it. Userspace could configure an invalid address (such as all zeroes or a multicast address) while the interface is down. Add a call to is_valid_ether_addr() and return -EADDRNOTAVAIL if the MAC address is not valid. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-5-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5d1c79a3d0ffe56879f6ef3e0a97847d8e73717a Author: Florian Fainelli Date: Mon Sep 21 15:00:19 2026 -0700 net: bcmgenet: do not skip WoL power up on GENET V1 [ Upstream commit cbbc1aee7776c7fa1d89e6cb963a23e58c495dca ] bcmgenet_power_up() had an early check for bcmgenet_has_ext(priv) before dispatching by power mode. GENET V1 does not have the EXT block (unlike GENET V2+), which causes bcmgenet_power_up() to immediately return 0. As a consequence, when waking up from GENET_POWER_WOL_MAGIC on GENET V1, bcmgenet_wol_power_up_cfg() is never invoked to disable the WoL clock, clear wake event masks, and restore normal PHY and MAC operations. Move the bcmgenet_has_ext() checks to the GENET_POWER_PASSIVE and GENET_POWER_CABLE_SENSE cases where the EXT registers are actually accessed, allowing GENET_POWER_WOL_MAGIC cleanup to execute on all hardware versions. Fixes: c3ae64ae0c08 ("net: bcmgenet: handle GENET_POWER_WOL_MAGIC") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-4-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58f7c4990e3017b6dba3c0fcf6b59e20d11088ed Author: Doug Berger Date: Thu Mar 6 11:26:41 2025 -0800 net: bcmgenet: allow return of power up status [ Upstream commit 2432b9817b7cb91aaae9e5032da0bb017cb3102d ] It is possible for a WoL power up to fail due to the GENET being reset while in the suspend state. Allow these failures to be returned as error codes to allow different recovery behavior when necessary. Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250306192643.2383632-14-opendmb@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: cbbc1aee7776 ("net: bcmgenet: do not skip WoL power up on GENET V1") Signed-off-by: Sasha Levin commit 1d0696cf3a0348a64525f3d9d5fe51aa46af55a1 Author: Doug Berger Date: Thu Mar 6 11:26:40 2025 -0800 net: bcmgenet: move bcmgenet_power_up into resume_noirq [ Upstream commit ffce2bedd361177718dc0c3787f4adb4785a0151 ] The bcmgenet_power_up() function is moved from the resume method to the resume_noirq method for symmetry with the suspend_noirq method. This allows the wol_active flag to be removed. The UMAC_IRQ_WAKE_EVENT interrupts that can be unmasked by the bcmgenet_wol_power_down_cfg() function are now re-masked by the bcmgenet_wol_power_up_cfg() function at the resume_noirq level as well. Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250306192643.2383632-13-opendmb@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: cbbc1aee7776 ("net: bcmgenet: do not skip WoL power up on GENET V1") Signed-off-by: Sasha Levin commit e62a605d40bc96c01a2dbfa6a95d7bbb0cef90e0 Author: Florian Fainelli Date: Mon Sep 21 15:00:18 2026 -0700 net: bcmgenet: initialize u64 stats seq counter for all queues [ Upstream commit 3aeaa609fda19c09d5298c9fedaaa3b6229601b5 ] bcmgenet_gstrings_stats statically defines ethtool statistics for queues 0 through GENET_MAX_MQ_CNT (4). However, bcmgenet_probe() only initialized the u64_stats_sync seq counter up to priv->hw_params->rx_queues and priv->hw_params->tx_queues. Since priv->hw_params->rx_queues is 0 across all hardware versions (and priv->hw_params->tx_queues is 0 on GENET V1), rings 1..4 have uninitialized u64_stats_sync structures. When ethtool -S is run on 32-bit kernels, bcmgenet_get_ethtool_stats() reads stats from rx_rings[1..4], causing lockdep warnings due to the uninitialized sequence counters. Initialize the sequence counters for all GENET_MAX_MQ_CNT + 1 queues. Fixes: ffc2c8c4a714 ("net: bcmgenet: Initialize u64 stats seq counter") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-3-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b6f674712b45c883e4191a445f6e1183fac0350 Author: Florian Fainelli Date: Mon Sep 21 15:00:17 2026 -0700 net: bcmgenet: fix 64-bit RTNL stats reading in ethtool on 32-bit systems [ Upstream commit 0e2bec77ea62895416600c90588f593516572bca ] When bcmgenet was converted to 64-bit statistics, STAT_RTNL members were switched to point into struct rtnl_link_stats64, whose fields are 64-bit (__u64) regardless of architecture. However, bcmgenet_get_ethtool_stats() retained a legacy check: if (sizeof(unsigned long) != sizeof(u32) && s->stat_sizeof == sizeof(unsigned long)) On 32-bit systems, sizeof(unsigned long) == sizeof(u32), causing this condition to evaluate to false. As a result, 64-bit RTNL stats fields were read via *(u32 *)p. On 32-bit Big-Endian systems (such as MIPS BE), this reads the high 32 bits and returns 0 until the counter exceeds 4GB; on 32-bit Little-Endian systems (such as 32-bit ARM), the value is truncated to 32 bits. Fix this by checking if s->stat_sizeof == sizeof(u64) so 64-bit fields are always read as 64-bit values. Fixes: 59aa6e3072aa ("net: bcmgenet: switch to use 64bit statistics") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-2-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a5b50c6dc01d0f55eefc49d9856863fe95a8884 Author: Ivan Delalande Date: Fri Sep 18 15:47:15 2026 -0700 tg3: use random MAC address when tg3_get_device_address fails [ Upstream commit 4eb3f195ef08c5acaed87958297e41cc49588dde ] Some of the tg3 NICs we use (BCM57762) reset the SRAM MAC address to the placeholder address on link flaps, tg3_chip_reset, etc. We've typically fixed it from userspace, but since e4c00ba7274b ("tg3: replace placeholder MAC address with device property") was merged, tg3 just fails probe as we don't have a way to get it through the generic device_get_mac_address infrastructure as fallback on our systems. Make the driver assign a random address in this condition instead of being fatal for probe. Set deferred_probe_reason through dev_warn_probe if the address isn't yet available from the provider. Fixes: e4c00ba7274b ("tg3: replace placeholder MAC address with device property") Suggested-by: Jakub Kicinski Link: https://lore.kernel.org/netdev/20260909191751.651aa5c4@kernel.org/ Signed-off-by: Ivan Delalande Link: https://patch.msgid.link/20260918224715.GA654128@visor Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a7489680bbd921333fb69e0188dc62427ebf3ef1 Author: Dragan Simic Date: Sun Sep 29 11:21:16 2024 +0200 driver core: Add device probe log helper dev_warn_probe() [ Upstream commit 36e69b160705b65bf136c2fb6a1194447eeb8478 ] Some drivers can still provide their functionality to a certain extent even when some of their resource acquisitions eventually fail. In such cases, emitting errors isn't the desired action, but warnings should be emitted instead. To solve this, introduce dev_warn_probe() as a new device probe log helper, which behaves identically as the already existing dev_err_probe(), while it produces warnings instead of errors. The intended use is with the resources that are actually optional for a particular driver. While there, copyedit the kerneldoc for dev_err_probe() a bit, to simplify its wording a bit, and reuse it as the kerneldoc for dev_warn_probe(), with the necessary wording adjustments, of course. Signed-off-by: Dragan Simic Tested-by: Hélène Vulquin Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2be0a28538bb2a3d1bcc91e2ca1f2d0dc09146d9.1727601608.git.dsimic@manjaro.org Signed-off-by: Mark Brown Stable-dep-of: 4eb3f195ef08 ("tg3: use random MAC address when tg3_get_device_address fails") Signed-off-by: Sasha Levin commit 0cba1457a020313a166dea0040e1064391876ec8 Author: Uwe Kleine-König Date: Thu Jun 13 23:23:52 2024 +0200 driver core: Make dev_err_probe() silent for -ENOMEM [ Upstream commit 2f3cfd2f4b7cf3026fe6b9b2a5320cc18f4c184e ] For an out-of-memory error there should be no additional output. Adapt dev_err_probe() to not emit the error message when err is -ENOMEM. This simplifies handling errors that might among others be -ENOMEM. Signed-off-by: Uwe Kleine-König Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/3d1e308d45cddf67749522ca42d83f5b4f0b9634.1718311756.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 4eb3f195ef08 ("tg3: use random MAC address when tg3_get_device_address fails") Signed-off-by: Sasha Levin commit 779f1d8f0d5e8a628fb289cfd0b4c2e36a16ea24 Author: Uwe Kleine-König Date: Fri Dec 15 18:45:41 2023 +0100 driver core: Better advertise dev_err_probe() [ Upstream commit 532888a59505da2a3fbb4abac6adad381cedb374 ] Describing the usage of dev_err_probe() as being (only?) "deemed acceptable" has a bad connotation. In fact dev_err_probe() fulfills three tasks: - handling of EPROBE_DEFER (even more than degrading to dev_dbg()) - symbolic output of the error code - return err for compact error code paths Advertise these better and claim the usage to be "fine" to get rid of the bad connotation. Acked-by: Rafael J. Wysocki Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20231215174540.2438601-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 4eb3f195ef08 ("tg3: use random MAC address when tg3_get_device_address fails") Signed-off-by: Sasha Levin commit ccdea7d8a91f7f9e0b9b99f63b138ff3e33244d8 Author: Johan Almbladh Date: Wed Sep 23 12:51:58 2026 +0200 bpf: Fix BSWAP 32 and 16 on MIPS64 [ Upstream commit 8110ba09777873443db286b3cbb89b0e6311c554 ] The 16/32-bit byteswap implementations for MIPS64r1 and earlier do not have an explicit zero extension afterwards. The input is first sign-extended to 64 bits, and the byteswap sequence can then leave the result sign-extended depending on the value of the low bits. Add the missing zero-extension. Found with test_bpf on MIPS64r1 emulated by QEMU. Fixes: fbc802de6b10 ("mips, bpf: Add new eBPF JIT for 64-bit MIPS") Signed-off-by: Johan Almbladh Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260923105158.3514342-2-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 1547e9f3a7d71971216e6dba30270cae13fe4e02 Author: Johan Almbladh Date: Wed Sep 23 12:51:57 2026 +0200 bpf: Fix immediate JMP JEQ/JNE on MIPS32 [ Upstream commit db762fd96be225bd06161c9631160c755d891693 ] An addu instruction was emitted instead of addiu, causing the immediate value 1 to be interpreted as register $at. This made the comparison result invalid when the immediate operand was negative. Note that $at is mapped to BPF_REG_AX, which is used for constant blinding. Fix the instruction to use the immediate form. Found with test_bpf on MIPS32r1 emulated by QEMU. Fixes: eb63cfcd2ee8 ("mips, bpf: Add eBPF JIT for 32-bit MIPS") Signed-off-by: Johan Almbladh Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260923105158.3514342-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 6debd72e3b3d0675e6086067923dedb5ba2dbe54 Author: Ido Schimmel Date: Tue Sep 22 16:12:39 2026 +0300 vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets [ Upstream commit ab7aa05c06ae340e5c7530bb78fa8d23794e460b ] The VRF device is an Ethernet device but it can have non-Ethernet ports such as IP tunnels. Before the cited commit, capturing packets from such ports on the VRF device resulted in these packets being detected as malformed since they lack an Ethernet header. The cited commit fixed it by pushing a dummy Ethernet header to such packets before the capture and pulling it afterwards. In the case of CHECKSUM_COMPLETE packets it also updated skb->csum with the checksum of the dummy Ethernet header. This is wrong as skb->csum should not include the checksum of the Ethernet header ("checksum of the _whole_ packet as seen by netif_rx()"). This also means that L4 protocols receive a corrupted skb->csum and potentially drop the packet, as is the case with UDP packets whose checksum was completed by software. Fix by removing the unnecessary call to skb_postpush_rcsum(). Fixes: 048939088220 ("vrf: add mac header for tunneled packets when sniffer is attached") Reported-by: Stefano Sasso Closes: https://lore.kernel.org/netdev/CALtE316UtL3x7LL6uxfXzx8rW6AbzYPeDOb478hqJCr_-dj=Wg@mail.gmail.com/ Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Reviewed-by: Eric Dumazet Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260922131239.2509494-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a0ad0473c09d2e947aecac5c82e637ec85924b12 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 1a5c5b9c64ba5f39dba55da6e12561ca56eeb758 Author: Jakub Kicinski Date: Mon Sep 21 16:18:56 2026 -0700 veth: manage XDP program pointers during channel resize [ Upstream commit 7104a370714346b667712913dc16abf14bbc97ed ] veth_set_channels() tears down XDP resources for removed RX queues without clearing rq->xdp_prog. If the program is then detached or replaced, those queues keep the old pointer after bpf_prog_put(). A later channel increase can re-enable NAPI and run the freed program. BUG: unable to handle page fault for address: ffffc90000256048 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: veth_xdp_rcv_skb (include/linux/filter.h:779 include/net/xdp.h:696 drivers/net/veth.c:820) Call Trace: veth_xdp_rcv (drivers/net/veth.c:941) veth_poll (drivers/net/veth.c:986) __napi_poll (net/core/dev.c:7787) net_rx_action (net/core/dev.c:7850 net/core/dev.c:8007) handle_softirqs (kernel/softirq.c:645) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 4752eeb3d891 ("veth: implement support for set_channel ethtool op") Signed-off-by: Weiming Shi Acked-by: Stanislav Fomichev Reviewed-by: Jiayuan Chen Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260921231856.1798630-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 453b0996ad2591afd339fa9d84becb79efed7cbd 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 8a0f1bb790d964893db7fc59febda9a534db07b3 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 a143f7835faa4fe0178448289feea4f84eeee8d6 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 32b5f0b338bf59391a1cff9a6190a72c4d2c1ba8 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 7579f0eb9325f61cc063975635996255f177b42e 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 3af2ea4035581a1607d9830779c187a0c7e225aa 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 755bfc409748d8f3df64eb0eb26926270de3dd77 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 3d691bd1b869a38ccad150b7423e4a4f2c127588 Author: Chris Gellermann Date: Fri Sep 4 18:42:52 2026 +0200 nfc: virtual_ncidev: Add missing ioctl compat handler [ Upstream commit 51814683e28fc64eceb415962376956c3cfc75a7 ] The compat handler for ioctls to the virtual nci device is missing. So, nci-specific ioctls of a compat task return with -1 and errno set to ENOTTY. Add a handler. The handling of an ioctl() call of a compat task to get the index of virtual nci device (IOCTL_GET_NCIDEV_IDX) lands in the default case of the ioctl compat handler (see fs/ioctl.c): COMPAT_SYSCALL_DEFINE3(ioctl, ...) { ... default: error = do_vfs_ioctl(fd_file(f), fd, cmd, ...); if (error != -ENOIOCTLCMD) break; if (fd_file(f)->f_op->compat_ioctl) error = fd_file(f)->f_op->compat_ioctl(fd_file(f), cmd, arg); if (error == -ENOIOCTLCMD) error = -ENOTTY; ... } There, do_vfs_ioctl() returns -ENOIOCTLCMD and compat_ioctl is not set for virtual_ncidev_fops, i.e. f_op->compat_ioctl == NULL. So, the ioctl() syscall returns with -1 and errno set to ENOTTY to the compat task. To fix this, use the compat_ptr_ioctl helper for compat handling here. It shall be used for ioctls that "either ignore the argument or pass a pointer to a compatible data type". The driver's sole ioctl takes a user void pointer and copies nfc_dev->idx to it, a 4-byte integer across all ABIs. This issue has been found by running the nci_dev kernel selftest as rv64 binary on top of a CHERI kernel, where the ioctl() ends up in the ioctl compat handler, similar to a 32-bit application on top of a 64-bit kernel. Fixes: e624e6c3e777 ("nfc: Add a virtual nci device driver") Signed-off-by: Chris Gellermann Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904164252.18351-1-christian.gellermann@codasip.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 2d226bd030d50a7efb74349d2df30119fc3a54f3 Author: Chris Gellermann Date: Fri Sep 4 11:59:15 2026 +0200 selftests/nci: Fix out-of-bounds store on thread join [ Upstream commit 6be581aeffc215bfc77939cd59902b0dbc4af23e ] The NCI test collects the exit status of its helper threads by passing the address of an int to pthread_join(): int status; ... pthread_join(thread_t, (void **) &status); pthread_join() stores a void pointer to the memory location. On 64-bit systems, a void pointer is wider than an int, so the store overruns the 4 bytes of space allocated on the stack for the integer and corrupts the adjacent stack. On our CHERI system, this caused a fault due to a capability bounds violation. Fix this by introducing a helper that joins a thread through a void pointer and converts the result back to an integer, which is what the helper threads return. While here, also fix the logic in disconnect_tag() if the helper thread creation failed. Previously, it would have joined a thread that was never created when pthread_create() failed. Fixes: f595cf1242f3 ("selftests: Add nci suite") Signed-off-by: Chris Gellermann Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904095915.3372241-1-christian.gellermann@codasip.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 9ccefca35f9a9a617e778cba2bcdc871023b4e04 Author: Chaithanya Lagisetty Date: Tue Sep 1 07:06:18 2026 +0000 selftests: nci: Fix uninitialized family ID on missing attribute [ Upstream commit eda518d2cdb6074a0bcdfa06af291616bcb5c421 ] get_family_id() walks the generic netlink CTRL_CMD_GETFAMILY reply looking for the CTRL_ATTR_FAMILY_ID attribute and returns the parsed value in the local variable "id". If the reply does not carry that attribute, the parsing loop never assigns "id" and the function returns an indeterminate stack value, which the caller stores in self->fid and uses for subsequent netlink requests. Initialize "id" to 0 so a missing attribute yields a deterministic (invalid) family ID instead of a garbage value. Fixes: f595cf1242f3 ("selftests: Add nci suite") Signed-off-by: Chaithanya Lagisetty Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260901070618.3299012-1-nagachaithanya9911@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit d2093a0981138876212bc5f473bdbfba0786e064 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 9d426ef871d07cab159b288f023c23d36949b582 Author: Lei Zhu Date: Wed Jul 29 15:24:26 2026 +0800 selftests: nci: Correct pthread_create return value check [ Upstream commit 3d8afc5243ea2ee803d98e69eb4a01748167ac1b ] The pthread_create() functions returns 0 on success and a positive value on failure. Modify the return value check to correctly detect failure cases. Fixes: 72696bd8a09d ("selftests: nci: Extract the start/stop discovery function") Signed-off-by: Lei Zhu Link: https://patch.msgid.link/20260729072426.303484-1-zhulei_szu@163.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit dba1d9c7134afcb4b1bfad8c1b1b3f0ab5189b08 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 f526c218a149a30f110ce434ff17e033042404b8 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 f15ad9d6e9173a037587dded77c904fdae8df380 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 3c090eb6f997617802bff85e428b308ab45bc324 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 9e602b97f6dca1ba4a23ebadeca3a176e2108341 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 3b29442159e21b1f212fd7accfff289fed37ff03 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 d45503c3ac34b44fca4f9edcf9107147deac2174 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 f9d929026d487a988bfa12c065f892e823e5b6ab Author: Xin Long Date: Mon Sep 21 14:03:45 2026 -0400 sctp: hold asoc or transport before mod_timer() in timer handlers [ Upstream commit cae23ae3f7887a1cf8a75da38edcebeef695040f ] Take the association or transport reference before rearming a timer in the timer handlers. The existing code calls mod_timer() before taking the reference needed by the rearmed timer without holding the sock lock. This creates a race with timer cleanup: if the timer is deleted after mod_timer() returns but before the reference is taken, the cleanup path can drop the timer's reference and destroy the transport or association. The timer handler then takes a reference on the already freed object and eventually drops it, causing a refcount underflow. Hold the object before mod_timer() and drop the reference if mod_timer() reports that the timer was already pending in timer handlers. Apply the same ordering to the proto-unreachable path, which can rearm a transport timer outside the timer handlers without holding the sock lock. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tangxin Xie Signed-off-by: Xin Long Link: https://patch.msgid.link/c31b5e3ee2b7274e804f5eba2f21e2412e7eef7a.1790013825.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 73388557b676f0000e57b784848daea2f7fa89d8 Author: Bernardo Soares Date: Fri Sep 18 10:59:31 2026 +0100 net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports [ Upstream commit 2e51097c982b7b22382fda3202ba29f0ea33e8c0 ] mlx5_esw_bridge_vport_unlink() returns -EINVAL when the port isn't tracked by this instance's br_offloads. This is reachable on a sibling instance that registered its notifier after the port was already enslaved: it never saw the NETDEV_CHANGEUPPER link event, so peer_link() never created a peer port for it, but it does see the later unlink event and fails. Return 0 instead, and give mlx5_esw_bridge_vport_peer_unlink() the same merged_eswitch capability guard peer_link() already has, since without it peer_link() likewise never creates a port to unlink. This also matters beyond the -EINVAL itself: mlx5_esw_bridge_switchdev_port_event() runs on the per-netns netdev_chain, and notifier_from_errno(-EINVAL) sets NOTIFY_STOP_MASK, which call_netdevice_notifiers_info() checks to stop calling further listeners on that chain - so the old -EINVAL silently dropped the event for any listener registered later on the same chain, even though none of it was visible to user space since __netdev_upper_dev_unlink() discards the return value. Fixes: c358ea1741bc ("net/mlx5: Bridge, allow merged eswitch connectivity") Signed-off-by: Bernardo Soares Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20260918095931.29792-3-bsoares.it@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8def32540609d1a7fd3b77a011542fd25f3eea1f Author: Vlad Buslov Date: Fri May 26 08:55:15 2023 +0200 net/mlx5: Bridge, pass net device when linking vport to bridge [ Upstream commit ade19f0d6a3a395e7936227811acbf897ee186fc ] Following patch requires access to additional data in bridge net_device. Pass the whole structure down the stack instead of adding necessary fields as function arguments one-by-one. Signed-off-by: Vlad Buslov Reviewed-by: Gal Pressman Signed-off-by: Saeed Mahameed Stable-dep-of: 2e51097c982b ("net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports") Signed-off-by: Sasha Levin commit c56191af3a578b9cc265fa3bd5fc0752c59c1781 Author: Zhao Gongyi Date: Thu Sep 17 20:10:16 2026 +0800 bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc [ Upstream commit 814a81c842bd88f6bd8a4ce550d560df071a5d03 ] sock_map_alloc() only rejects max_entries == 0 and otherwise allows any u32 value. sock_map_free() then walks the sks[] array with a signed int iterator: int i; for (i = 0; i < stab->map.max_entries; i++) struct sock **psk = &stab->sks[i]; When a SOCKMAP is created with max_entries = 0xffffffff (UINT_MAX), the allocation of 32 GiB can succeed on large-memory hosts. During free the counter reaches 0x80000000, wraps to INT_MIN, is sign-extended by movslq and turned into a ~16 GiB negative offset from stab->sks, pointing far below the allocation. The faulting access is an xchg() write in sock_map_free(). Without KASAN, the same out-of-bounds write can fault on an unmapped vmalloc page or corrupt an unrelated allocation if that vmalloc address is populated. On a KASAN kernel with CONFIG_KASAN_VMALLOC=y, the shadow check for that address hits an unmapped shadow page and oopses first: BUG: unable to handle page fault for address: fffff521b59c5a00 RIP: 0010:kasan_check_range+0x107/0x190 Call Trace: sock_map_free+0x93/0x190 map_create+0x68d/0xb30 __sys_bpf+0x21e/0x2e70 Vmcore confirmed stab->map.max_entries == 0xffffffff, stab->sks == 0xffffc911ace2d000, and the faulting address sks + (s64)INT_MIN * 8 exactly at 0xffffc90dace2d000. The same buggy path is reached on the normal close()/bpf_map_free_deferred() path whenever such a map is destroyed. sock_map_alloc() used to bound its allocation size through bpf_map_charge_init(), but the bound was dropped when rlimit-based memory accounting was removed. Reject max_entries > INT_MAX at creation time so the signed iterator in sock_map_free() never sees a value that would overflow. Triggered by syzkaller and reproduced on both a 6.6-based KASAN kernel and the upstream v7.3-rc2 kernel. Fixes: 0d2c4f964050 ("bpf: Eliminate rlimit-based memory accounting for sockmap and sockhash maps") Signed-off-by: Zhao Gongyi Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260917121016.48171-1-zhaogongyi@bytedance.com Signed-off-by: Sasha Levin commit 70288599d1754e157df8326239316dbdf08ea33c 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 4a04b2cef2b51124c11c2a1629232eda65d49026 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 a19bede30f0da5ae56782edac62b5998a7434cba Author: Mikhail Zaslonko Date: Wed Sep 16 18:06:26 2026 +0200 s390/debug: Fix NULL pointer dereference in debug_info_copy() [ Upstream commit 012bfcd5a51082d5a65f096dfb9ca652b5267965 ] When debug_register_static() fails, it clears areas, active_pages and active_entries but leaves the area bounds unchanged. Copying such an area, either by opening its view file or via debug_dump(), makes debug_info_copy() dereference the NULL pointers. Skip the copy loop when the source has no areas. Closes: https://lore.kernel.org/r/20260903132123.12F271F00A3F@smtp.kernel.org Fixes: d72541f94512 ("s390/debug: add early tracing support") Signed-off-by: Mikhail Zaslonko Reviewed-by: Peter Oberparleiter Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit beceb68b122f9b5e5f44575b3e1f35d620b8518b Author: Mikhail Zaslonko Date: Fri Sep 18 17:13:51 2026 +0200 s390/debug: Do not register views for failed static debug areas [ Upstream commit 28e29992b034acffc9342df216c06097825ce610 ] __REGISTER_STATIC_DEBUG_INFO() calls debug_register_view() unconditionally, even when debug_register_static() has failed. In that case _debug_register() was never reached and id->debugfs_root_entry is still NULL, so debugfs_create_file() places the view file in the debugfs root directory. For sclp_err this leaves a /sys/kernel/debug/hex_ascii file with nothing to indicate which debug log it belongs to. debug_register_static() is not exported and the macro is its only caller, so let it return an error code and skip the view registration when it fails. No debugfs files are created for such an area then. Reproduce by booting with s390dbf=sclp_err::100000000. The sclp_err registration fails, no s390dbf/sclp_err/ directory is created, and a hex_ascii file appears in the debugfs root instead. Fixes: d72541f94512 ("s390/debug: add early tracing support") Signed-off-by: Mikhail Zaslonko Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 0844402326d4e48a28688f93ec6442e93bb442fa 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 8488779d9bddbdb33588c9fc2c0657a3da773f61 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 7a1781a2f3a9667b3065d402d1f11986a2363e08 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 3e605ff5932afe0970c2beca66f2f1ba2babe4dd 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 5118b5fdf1eb9922a0cdd2afd25252081e2d4302 Author: Junrui Luo Date: Tue Sep 15 15:39:13 2026 +0800 drm/virtio: release the GEM object on virtio_gpu_vram_create() errors [ Upstream commit 036d28db1818af2f9d80db771f5405da84d7732d ] virtio_gpu_vram_create() frees the object with a bare kfree(vram) on both error paths after drm_gem_private_object_init() has run, and on the second one after drm_gem_create_mmap_offset() has linked obj->vma_node into the device's VMA offset manager. The freed object stays in that interval tree, so a later lookup or insertion walks freed memory, and the dma_resv and gpuva lock are never destroyed. Call drm_gem_object_release() before kfree() on both paths. Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram object") Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-4-a0d799e4db66@outlook.com Signed-off-by: Sasha Levin commit eea473532a286cd1b13cddbec5c645989f43a3aa Author: Junrui Luo Date: Tue Sep 15 15:39:12 2026 +0800 drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl() [ Upstream commit 24b6d5c7641412c9ebef0d4c8b888d49a0e6b880 ] virtio_gpu_resource_create_blob_ioctl() calls drm_gem_object_release() on both the virtio_gpu_resource_assign_uuid() and drm_gem_handle_create() error paths instead of dropping the reference it owns, so obj->funcs->free() never runs and the virtio_gpu_object, the resource id and the host-side resource are leaked. Use drm_gem_object_put() instead. Fixes: 897b4d1acaf5 ("drm/virtio: implement blob resources: resource create blob ioctl") Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-3-a0d799e4db66@outlook.com Signed-off-by: Sasha Levin commit 83c899104496677068fbbd2e42f28fd625f9cd85 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 264ae8ac8fd625b6c118baf16c111adeee2ec632 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 f476fb656ca2326d7b2eba98d03ced1cbcf5cd99 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 4cc0a8eb2f9336cfa3e4ac329bc5585ca970ced3 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 d893a7cc1cb41dd510f338bb2bfd8f29b14eaf49 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 36359e3e09ea3785f24775bce410a0c6640ef99a 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 1eeec0c51fd5598da44080ed96bbd9880021c28b 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 424ba52c0058deeb940d02cba52eb0aeb288db33 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 0f6410e3795b23dd8f1e46946ef23195935db787 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 492e9cfa12f35f7946ea1b78a19f1f9337d62248 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 c2b24dd0ee16e568fc5286354aa581a83975b10f 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 687d0c8d47c3f1e8d56bcfad7569506cf48d3f1a Author: Naman Gulati Date: Sat Sep 12 01:10:51 2026 +0000 netfilter: ctnetlink: fix suspicious RCU usage in expect_iter_name [ Upstream commit 207d591c353201f3bd3e0c89bb7d44a849c8fd59 ] expect_iter_name() is invoked by nf_ct_expect_iterate_net() under spin_lock_bh(&nf_conntrack_expect_lock). It does not hold rcu_read_lock(). When accessing exp->helper with rcu_dereference() in syzbot's report, lockdep warns: ============================= WARNING: suspicious RCU usage syzkaller #0 Not tainted ----------------------------- net/netfilter/nf_conntrack_netlink.c:3393 suspicious rcu_dereference_check() usage! locks held by syz-executor381/5628: 2, last CPU#1: #0: ffffffff9aee42a0 (nfnl_subsys_ctnetlink_exp){+.+.}-{4:4}, at: nfnetlink_rcv_msg+0xa69/0x12b0 #1: ffffffff8ea74d58 (nf_conntrack_expect_lock){+...}-{3:3}, at: nf_ct_expect_iterate_net+0x38/0x180 Call Trace: dump_stack_lvl+0xe8/0x150 lockdep_rcu_suspicious+0x140/0x1d0 expect_iter_name+0xfb/0x100 nf_ct_expect_iterate_net+0xf2/0x180 ctnetlink_del_expect+0x45d/0x640 nfnetlink_rcv_msg+0xcc2/0x12b0 netlink_rcv_skb+0x226/0x4a0 nfnetlink_rcv+0x2b9/0x28c0 netlink_unicast+0x7bd/0x940 netlink_sendmsg+0x813/0xb40 ____sys_sendmsg+0x54e/0x850 ___sys_sendmsg+0x2a5/0x360 __sys_sendmsg+0x2a5/0x360 do_syscall_64+0x166/0x520 entry_SYSCALL_64_after_hwframe+0x77/0x7f Use rcu_dereference_protected() with lockdep_is_held() on nf_conntrack_expect_lock instead, similar to expect_iter_me() in nf_conntrack_helper.c. Fixes: f01794106042 ("netfilter: nf_conntrack_expect: use expect->helper") Reported-by: syzbot+4bd730aede2791e40bdf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6aa4a377.f81106d8.2ab401.0024.GAE@google.com/T/#u Signed-off-by: Naman Gulati Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2232e5da56d436eb0eeee5d23a3492678de4f7a2 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 75de64b208f71de6df18fbeddb725d19c9fa4c04 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 2e9be1302f25c9be51c2fb8c907bc6d8a1050e33 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 5d7c8f8c8da9f3c639f2be83d306224e3254a866 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 56f39c7d139bb76072efe2fb3dcafc13ba915ad8 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 93212db295719c3caea7a4a41edf84272c4374b4 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:18 2026 +0200 libbpf: Reject truncated ldimm64 CO-RE relocations [ Upstream commit b4e875d397da451fb4e9c573ff4b86db53caba05 ] CO-RE relocation of an ldimm64 instruction operates on two instruction slots. A malformed BPF ELF can end a function after the first slot and attach a CO-RE relocation to it. libbpf allocates the instruction array according to the function symbol size, so the shared relocation code would then access beyond the allocation. Reject a terminal ldimm64 in libbpf's relocation loop, where the program length is available, before resolving or applying the relocation. Both resolved and unresolved relocations validate the absent second slot, and unresolved relocation poisoning would additionally write past the array. The in-kernel caller is protected by the verifier's early instruction-stream check before it applies CO-RE relocations. Fixes: eacaaed784e2 ("libbpf: Implement enum value-based CO-RE relocations") Reported-by: Sashiko Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/20260914140852.03DA21F0089B@smtp.kernel.org Link: https://patch.msgid.link/20260917233222.2542500-11-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit d3219c229d16900cef936adad28633c98946e432 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:14 2026 +0200 bpf: Restrict CO-RE poisoning to relocatable instructions [ Upstream commit 394ae398337c5f87e567f6cd63b937fc2b2f6ddc ] CO-RE relocation records can name any instruction offset. When a relocation cannot be resolved, bpf_core_patch_insn() currently poisons its target before checking whether that instruction is a valid relocation target. Malformed metadata can therefore replace jumps, calls, exits, register-source arithmetic, or non-immediate loads instead of failing at the relocation step. Handle poisoning only after the instruction has passed the same class and operand-form checks used for a resolved relocation. Route invalid forms through the existing diagnostic and return a hard error. Keep poisoning supported instructions, including both halves of a plain ldimm64, so an unresolved relocation in dead code remains valid. Extend bpf_core_poison_insn() to poison both halves of ldimm64, and return its status directly from each validated instruction case. This avoids routing the success path through a common label and leaves the helper free to report errors. The shared relocation code applies this restriction to both libbpf and in-kernel CO-RE. Fixes: d7a252708dbc ("libbpf: Improve handling of failed CO-RE relocations") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-7-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 21fc07924e996e1e661268ca269c86b8d59d25b3 Author: Jamal Hadi Salim Date: Wed Sep 16 06:01:14 2026 -0400 net/sched: cls_u32: fix manual hash table handle IDR aliasing [ Upstream commit 0a5f5d9e94dead312d32c366b917c64e552b72f7 ] A u32 hash table created with an explicit handle ('tc filter add ... handle 801: u32 divisor N') keys its IDR entry on the raw handle, while the destroy paths free it under handle2id(handle). The two key domains disagree for handles in the 0x800..0xFFF htid range: handle2id() folds them back into the auto-allocated id space (1..0x7FF). A manual table therefore leaves its raw-keyed IDR entry unreachable on delete (a permanent leak), and its delete can drop the idr entry of an unrelated live auto table. A later auto allocation can then hand out a handle that aliases the live manual table; u32_lookup_ht() first-match routes lookups and TCA_U32_LINK for that htid to the wrong table. Key the divisor-path alloc on handle2id(handle) so allocation and removal share one key domain. A manual handle that maps onto an id already in use is rejected with -ENOSPC, and auto allocation skips ids held by live manual tables. Conditions to recreate: ip link add test0 type dummy tc qdisc add dev test0 clsact tc filter add dev test0 ingress protocol ip pref 1 \ handle 801: u32 divisor 16 tc filter add dev test0 ingress protocol ip pref 2 u32 divisor 16 tc -d filter show dev test0 ingress | grep 'fh 801:' # unpatched: two live tables with handle 0x80100000 (the pref 2 root # hnode is auto-allocated id 1); patched: the auto hnode takes id 2. Also tested with a poc with a live u32 table on the block, add/delete a manual table 'handle 901: u32 divisor 1' twice; unpatched, the re-add fails with -ENOSPC because the raw key leaked on the first delete. Fixes: 73af53d82076 ("net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for hnodes.") Reported-by: Sashiko (gemini + nipa) Closes: https://sashiko.dev/#/patchset/20260822222049.114526-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-LQFE.v1.20260911041746.1@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68930f8d40ab4c10ca3b019f076136758fd100a8 Author: Weiming Shi Date: Tue Sep 15 01:02:07 2026 +0800 bpf: Skip unsettled links in link iterator [ Upstream commit 50e80e2bb5e2be8515205b9c496b9640ddefa434 ] bpf_link_prime() inserts a link into link_idr before anon_inode_getfile() succeeds and before bpf_link_settle() publishes the ID in link->id. bpf_link_by_id() treats such an ID-zero link as unsettled, but the link iterator takes a reference without this check. If anon_inode_getfile() then fails, the creator removes the ID and frees its still-private link directly. The iterator is left with a dangling reference and its next bpf_link_put() accesses freed memory. Treat ID-zero entries as transient in bpf_link_get_curr_or_next(), just as bpf_link_by_id() does. BUG: KASAN: slab-use-after-free in bpf_link_put Write of size 8 by task exp/384 Call Trace: bpf_link_put kernel/bpf/syscall.c:3372 bpf_link_seq_next kernel/bpf/link_iter.c:33 bpf_seq_read kernel/bpf/bpf_iter.c:158 vfs_read fs/read_write.c:572 ksys_read fs/read_write.c:716 do_syscall_64 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:121 Kernel panic - not syncing: KASAN: panic_on_warn set ... Fixes: 9f8836127308 ("bpf: Add bpf_link iterator") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260914170206.170723-2-bestswngs@gmail.com Signed-off-by: Sasha Levin commit 11d9be35c1f4233798e99be98bc474f83a254c6c 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 c5a58bc5d9d6d7b01638c693f01a1252489b193f Author: Vineeth Vijayan Date: Thu Sep 10 11:32:02 2026 +0200 s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points [ Upstream commit f6f2985eabdb2bfdc82ce90a1ea3ec53ba795f34 ] The device number valid (dnv) bit in the PMCW must be checked before acting on any other PMCW fields for IO-type subchannels. A subchannel with dnv=0 has no valid device number associated, making it meaningless to evaluate the enabled (ena) state or issue any I/O instruction against it. Reported-by: William Bezenah Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Fixes: 8c58a229688c ("s390/cio: Do not unregister the subchannel based on DNV") Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit c02fdcb0c0325306359e0d84f4134575981e4713 Author: Vineeth Vijayan Date: Thu Sep 10 11:32:01 2026 +0200 s390/cio: Fix cio_update_schib() to not cache invalid schib [ Upstream commit 29d9e5835d89223aa913dcf7b942cc1c148bdd25 ] When pmcw.dnv is 0, the contents of all SCHIB fields are unpredictable. Zero sch->schib in that case to prevent subsequent code from making decisions based on unpredictable data. Reported-by: William Bezenah Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Fixes: 8c58a229688c ("s390/cio: Do not unregister the subchannel based on DNV") Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 0242dcf4caf5ef6f48ee2d1574db91b529f6f760 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 7a3d43603744050412c19a9c77f54f8e35b29498 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 d040268554e3dd61e198d7d15115e549a4a36bad 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 78f1147e2122fbc2534fa290bad67cbd48f92fc3 Author: Bart Van Assche Date: Mon Aug 31 12:27:20 2026 -0700 scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume() [ Upstream commit 42d1221d321e55afc7bba9109a77aaf5a817c8a3 ] Protect the megasas_get_ctrl_info() call in megasas_resume() with instance->reset_mutex using scoped_guard(). megasas_get_ctrl_info() may release and reacquire instance->reset_mutex. Hence, calling this function without holding instance->reset_mutex is not safe. Fixes: c3b10a55abc9 ("scsi: megaraid_sas: Update controller info during resume") Cc: Kashyap Desai Cc: Sumit Saxena Cc: Shivasharan S Cc: Chandrakanth patil Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/f06b5ee432b21cf293f0663e15b64f75a84b9fd5.1788204406.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit f84e52829021d00bca8e067302f597c71af1f71a Author: Lee Jones Date: Tue Sep 15 12:08:22 2026 +0000 Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel [ Upstream commit 71af682ba4692c2ed9ace4c3d4ca462ae368c029 ] In send_cancel(), pending mesh_tx objects are removed from the hdev->mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev->cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx. When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free. Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly. Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev->cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Signed-off-by: Lee Jones Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5fc9e1393555fd35a66f5b31f7e259a357455cfc 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 7a1c293e7aa17f1afaee0684e0e931fe23a5a6b1 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 7b3747d77767f066ccf4a9e8e3a8381643ab5368 Author: Slawomir Stepien Date: Mon Sep 14 11:50:07 2026 +0200 HID: amd_sfh: Validate PCI BAR size before mapping [ Upstream commit 65bcc5f89704efe5b9d69d4ea2c1002d90c31382 ] The amd_sfh driver maps PCI BAR 2 using pcim_iomap_regions() and subsequently accesses MMIO registers at offsets up to 0x10958 (e.g., AMD_P2C_MSG3 at 0x1068C). However, the driver never validates that the BAR size is large enough to cover these accesses. If the driver is bound to a device with a smaller BAR 2, this leads to an out-of-bounds memory access and a page fault during the probe function. For example, a page fault can occur when reading from privdata->mmio + AMD_P2C_MSG3 in mp2_select_ops(): BUG: unable to handle page fault for address: ffffc9000390368c PGD 100000067 P4D 100000067 PUD 1012c1067 PMD 105b64067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:mp2_select_ops drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:282 [inline] RIP: 0010:amd_mp2_pci_probe+0x337/0x5f0 drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:487 Call Trace: local_pci_probe drivers/pci/pci-driver.c:332 [inline] pci_call_probe drivers/pci/pci-driver.c:394 [inline] __pci_device_probe drivers/pci/pci-driver.c:455 [inline] pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489 Fix this by verifying that the length of BAR 2 is at least 128KB before attempting to map it. Since the maximum accessed offset is 0x10958, and PCI BAR sizes are powers of 2, any legitimate hardware will have a BAR size of at least 128KB. Fixes: 4f567b9f8141 ("SFH: PCIe driver to add support of AMD sensor fusion hub") Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+4eadd4dfe9e66522bae8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8 Link: https://syzkaller.appspot.com/ai_job?id=3bc1c45c-548f-4ab5-8243-d2c8ec321d6c Signed-off-by: Slawomir Stepien Acked-by: Basavaraj Natikar Link: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8 Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cd2e5ffe877a5f1e6ee50c1482c92b521f4d0e5d Author: Sean Anderson Date: Mon Aug 17 12:22:11 2026 -0400 pinctrl: meson: Fix typo in s4 group name [ Upstream commit 692f32609a30f75ca3401e25b504bfd06bd5662a ] One of the i2c pin groups has some junk at the end. The name should be i2c2_scl_h1, and indeed that's the name used by i2c2_pins3 in meson-s4.dtsi. Fixes: 775214d389c25 ("pinctrl: meson: add pinctrl driver support for Meson-S4 Soc") Signed-off-by: Sean Anderson Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cf9aefb26a071cb8b6fdd761c27e022a1184946d Author: Geliang Tang Date: Tue Sep 8 17:08:32 2026 +0800 bpf, sockmap: Fix self-redirect copied_seq double-counting [ Upstream commit 490a83d6386eec1d29f470c8d7331677fb46c3b7 ] When a BPF stream_verdict program redirects an skb back to the same socket (self-redirect with BPF_F_INGRESS), sk_psock_verdict_apply() calls tcp_eat_skb() which advances tcp_sk->copied_seq. However, the skb is then delivered to the socket's psock ingress queue and later read by tcp_bpf_recvmsg_parser(), which also advances copied_seq via the copied_from_self accounting path. This double-counting causes copied_seq to advance by 2x the actual data length, triggering: TCP recvmsg seq # bug 2: copied BF2E806, seq BF2E7FD, \ rcvnxt BF2E806, fl 0 WARNING: net/ipv4/tcp.c:2745 at tcp_recvmsg_locked+0x72b/0x2640 Call Trace: tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f cleanup rbuf bug: copied BF2E806 seq BF2E806 rcvnxt BF2E806 WARNING: net/ipv4/tcp.c:1609 at tcp_cleanup_rbuf+0xf2/0x1c0 Call Trace: tcp_recvmsg_locked+0x8d1/0x2640 tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by converting self-redirect verdict to __SK_PASS at the beginning of sk_psock_verdict_apply(). This bypasses the __SK_REDIRECT case entirely (which calls sk_psock_eat_skb), letting the __SK_PASS path queue the skb to the psock ingress queue. The data is then read via tcp_bpf_recvmsg_parser(), which advances copied_seq exactly once through copied_from_self. Cross-socket redirects continue through __SK_REDIRECT with sk_psock_eat_skb() unchanged. Fixes: e5c6de5fa025 ("bpf, sockmap: Incorrectly handling copied_seq") Suggested-by: Jakub Sitnicki Suggested-by: Jiayuan Chen Signed-off-by: Geliang Tang Reviewed-by: Emil Tsalapatis Reviewed-by: Jiayuan Chen Link: https://lore.kernel.org/r/1a8e797a1b26e2f695aaac22ac644c2862f63466.1788858299.git.tanggeliang@kylinos.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fd6bf2721933d8c90bc4ce57f3e204c9295e7e3f 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 ca5bd55fc508fbb5c08c62206d02237a5b6fc7e8 Author: Jose Fernandez (Anthropic) Date: Wed Sep 9 17:51:04 2026 +0000 bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch() [ Upstream commit 85136bf22404474a815fc0ed26ec0d1cbc1bc3f9 ] __htab_map_lookup_and_delete_batch() has no rescheduling point. The batch count bounds how many entries are copied out, not how many buckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the map end to end. The empty-bucket fast path is worse: it stays inside a single rcu_read_lock() / bpf_disable_instrumentation() section for any run of consecutive empty buckets. That holds up on small maps, but it falls apart at scale. On a 144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic BPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216 buckets held a CPU inside the batch op for 77+ seconds and triggered the soft lockup watchdog. Commit 75134f16e7dd ("bpf: Add schedule points in batch ops") fixed this same problem in the generic batch ops, but not in this htab-native path, which every htab-based hash map variant uses for its lookup[_and_delete] batch ops. Complete that fix here. Leave the critical section after 64 consecutive empty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved bucket cursor. No locks are held at that point, and resuming from the cursor is already the function's behavior for non-empty buckets. Add the same call to the per-bucket loop after copy_to_user(), where every lock has been dropped. cond_resched_rcu() is not enough here: sleeping with bpf_prog_active elevated makes tracing programs on that CPU silently skip their invocations. Plain cond_resched() is not enough either. It is a no-op under PREEMPT and PREEMPT_LAZY, the only models arm64 and x86 have offered since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"). It is also never a Tasks RCU quiescent state, in any model: the reschedule counts as a preemption. The walking task stays a holdout and stalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline teardown included, until the syscall returns [1]. cond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports the quiescent state at each yield and still reschedules as cond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels. Fixes: 057996380a42 ("bpf: Add batch ops to all htab bpf map") Cc: "Paul E. McKenney" Cc: Rik van Riel Link: https://lore.kernel.org/bpf/20260715215314.44423f47@fangorn/ [1] Link: https://lore.kernel.org/bpf/9d444098-7c03-4163-af12-bd0a79a51443@paulmck-laptop/ [2] Assisted-by: LLM Signed-off-by: Jose Fernandez (Anthropic) Signed-off-by: Josef Bacik Reviewed-by: Rik van Riel Link: https://lore.kernel.org/r/20260909-b4-htab-batch-resched-v2-1-0cb529d8f95a@toxicpanda.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 11d1c0dab6a45fb58b3eee7c2d7b0668079c2eb6 Author: Oscar Priego Verdugo Date: Mon Aug 17 06:05:46 2026 -0600 HID: elecom: fix bus type for M-XGL20DLBK [ Upstream commit 8e2a4b458ad25e13422bb059758c30a6562aa9cf ] The M-XGL20DLBK is matched as a USB device by hid-elecom, but its entry in hid_have_special_driver[] uses HID_BLUETOOTH_DEVICE. This prevents the special-driver quirk entry from matching the USB device handled by hid-elecom. Use HID_USB_DEVICE there as well. Fixes: 55633e681afb ("HID: elecom: add support for EX-G M-XGL20DLBK wireless mouse") Signed-off-by: Oscar Priego Verdugo Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 172756f02663ad45c889c001c1a8cb4082a01a05 Author: Jiayuan Chen Date: Thu Sep 10 20:22:55 2026 +0800 bpf: Fix divide-by-zero in btf_struct_walk() [ Upstream commit b0b3dc66529676228cb938cbcad66920f735c223 ] When an access goes past the struct and the last member is a flexible array, btf_struct_walk() folds the offset back into a single element with (off - moff) % t->size, but never checks that the element type has a size. BTF takes an empty struct, so this in program BTF /* event could be empty */ struct event { #ifdef HAVE_TIMESTAMP __u64 ts; #endif }; struct batch { int nr; struct event events[]; }; divides by zero at prog load time. Getting there needs a PTR_TO_BTF_ID that is not MEM_ALLOC, e.g. a plain read of a local kptr stashed in a map from a sleepable program. Oops: divide error: 0000 [#1] SMP KASAN PTI RIP: 0010:btf_struct_walk+0x53f/0x1570 Call Trace: btf_struct_access+0x42a/0xcd0 check_ptr_to_btf_access+0x4dc/0x1160 check_mem_access+0x3a45/0x8740 check_load_mem+0x36a/0xd10 do_check_common+0x3ef0/0xb210 bpf_check+0x6d3b/0x8580 bpf_prog_load+0xf7c/0x2720 __sys_bpf+0xa83/0x3690 __x64_sys_bpf+0xc7/0x150 x64_sys_call+0x1f3f/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Reject a zero-sized element type. The fixed array path in the same function already bails out on the same thing: btf_struct_walk() ... /* skip empty array */ if (moff == mtrue_end) continue; msize /= total_nelems; Fixes: 9c5f8a1008a1 ("bpf: Support variable length array in tracing programs") Signed-off-by: Jiayuan Chen Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260910122316.186384-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 45c2daf49d5006cc5d35e8a7eb129f64c9e09ae3 Author: Feng Zhou Date: Thu Apr 20 11:27:34 2023 +0800 bpf: support access variable length array of integer type [ Upstream commit 2569c7b8726fc06d946a4f999fb1be15b68f3f3c ] After this commit: bpf: Support variable length array in tracing programs (9c5f8a1008a1) Trace programs can access variable length array, but for structure type. This patch adds support for integer type. Example: Hook load_balance struct sched_domain { ... unsigned long span[]; } The access: sd->span[0]. Co-developed-by: Chengming Zhou Signed-off-by: Chengming Zhou Signed-off-by: Feng Zhou Link: https://lore.kernel.org/r/20230420032735.27760-2-zhoufeng.zf@bytedance.com Signed-off-by: Alexei Starovoitov Stable-dep-of: b0b3dc665296 ("bpf: Fix divide-by-zero in btf_struct_walk()") Signed-off-by: Sasha Levin commit c2a65da19a131e6d04331d9d19732cdf6138dcef 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 9f9e57b5a3a033f95f49ef9d541340cdbcb80abb 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 090dd031fa491fca424599ae0df977fd29bd2096 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 6fb177f10d87b8d816402c488e83506d0fb5340a Author: Xingui Yang Date: Fri Sep 25 15:56:21 2026 -0400 scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list [ Upstream commit 71fb36b5ff113a7674710b9d6063241eada84ff7 ] When freeing slots in function slot_complete_v3_hw(), it is possible that sas_dev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows: ==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe() [ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5 [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored [ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [ 7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw] [ 7165.485247] sp : ffff00001d623bc0 [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [ 7165.567872] Call trace: [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main] [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas] [ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas] [ 7165.592082] scsi_error_handler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] ret_from_fork+0x10/0x18 [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception To fix the issue, grab sas_dev lock when traversing the members of sas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid concurrency of adding and deleting member. When function hisi_sas_release_tasks() calls hisi_sas_do_release_task() to free slot, the lock cannot be grabbed again in hisi_sas_slot_task_free(), then a bool parameter need_lock is added. Signed-off-by: Xingui Yang Signed-off-by: Xiang Chen Link: https://lore.kernel.org/r/1679283265-115066-2-git-send-email-chenxiang66@hisilicon.com Signed-off-by: Martin K. Petersen [ Backport to 6.1.y: omit the SATA NCQ-error call-site update because that path does not call hisi_sas_do_release_task() in 6.1.y. The list locking change is otherwise identical to upstream. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 7e0ee4cb02e6b485103ecd125743b2818a68993d Author: Boris Burkov Date: Fri Sep 25 15:53:48 2026 -0400 btrfs: insert tree mod log move in push_node_left [ Upstream commit 5cead5422a0e3d13b0bcee986c0f5c4ebb94100b ] There is a fairly unlikely race condition in tree mod log rewind that can result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 This occurs when logical inode resolution takes a tree mod log sequence number, and then while backref walking hits a rewind on a busy node which has the following sequence of tree mod log operations (numbers filled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 When this sequence gets applied via btrfs_tree_mod_log_rewind, it allocates a fresh rewind eb, and first inserts the correct key info for the 533 elements, then overwrites the first 456 of them, then decrements the count by 456 via the add ops, then rewinds the move by doing a memmove from 456:988->0:532. We have never written anything past 532, so that memmove writes garbage into the 0:532 range. In practice, this results in a lot of fully 0 keys. The rewind then puts valid keys into slots 0:455 with the last removes, but 456:532 are still invalid. When search_old_slot uses this eb, if it uses one of those invalid slots, it can then read the extent buffer and issue a bio for offset 0 which ultimately panics looking up extent mappings. This bad tree mod log sequence gets generated when the node balancing code happens to do a balance_node_right followed by a push_node_left while logging in the tree mod log. Illustrated for ebs L and R (left and right): L R start: [XXX|YYY|...] [ZZZ|...|...] balance_node_right: [XXX|YYY|...] [...|ZZZ|...] move Z to make room for Y [XXX|...|...] [YYY|ZZZ|...] copy Y from L to R push_node_left: [XXX|YYY|...] [...|ZZZ|...] copy Y from R to L [XXX|YYY|...] [ZZZ|...|...] move Z into emptied space (NOT LOGGED!) This is because balance_node_right logs a move, but push_node_left explicitly doesn't. That is because logging the move would remove the overwritten src < dst range in the right eb, which was already logged when we called btrfs_tree_mod_log_eb_copy. The correct sequence would include a move from 456:988 to 0:532 after remove 0:455 and before removing 0:532. Reversing that sequence would entail creating keys for 0:532, then moving those keys out to 456:988, then creating more keys for 0:455. i.e., REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 MOVE src slot 456 -> dst slot 0 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 Fix this to log the move but avoid the double remove by putting all the logging logic in btrfs_tree_mod_log_eb_copy which has enough information to detect these cases and properly log moves, removes, and adds. Leave btrfs_tree_mod_log_insert_move to handle insert_ptr and delete_ptr's tree mod logging. (Un)fortunately, this is quite difficult to reproduce, and I was only able to reproduce it by adding sleeps in btrfs_search_old_slot that would encourage more log rewinding during ino_to_logical ioctls. I was able to hit the warning in the previous patch in the series without the fix quite quickly, but not after this patch. CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba [ Backport to 6.1.y: retain the older btrfs_node_key_ptr_offset() call signature and pass GFP_NOFS to alloc_tree_mod_elem(). The tree-mod-log ordering change is otherwise identical to upstream. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 60ee0f6fea7ba5681ebf7d70b8ebe592227188a4 Author: Dmitry Antipov Date: Thu Sep 24 13:40:53 2026 -0400 wifi: rtw88: delete timer and free skb queue when unloading [ Upstream commit 634fcbcaa4062db39aeb5ac6ed1bc1feb8dd5216 ] Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope. Reviewed-by: Ping-Ke Shih Signed-off-by: Dmitry Antipov Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230628072327.167196-1-dmantipov@yandex.ru [ Backport to 6.1.y: the source change is unchanged; only hunk locations in rtw_core_deinit() differ. The target-only Fixes trailer names the initial rtw88 driver commit, which introduced this lifetime. ] Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit ff635d1f143b55fa005e9e43b16e6d8f677e90a5 Author: Duoming Zhou Date: Thu Sep 24 13:38:41 2026 -0400 sh: push-switch: Reorder cleanup operations to avoid use-after-free bug [ Upstream commit 246f80a0b17f8f582b2c0996db02998239057c65 ] The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations. Fixes: 9f5e8eee5cfe ("sh: generic push-switch framework.") Signed-off-by: Duoming Zhou Reviewed-by: Geert Uytterhoeven Reviewed-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/r/20230802033737.9738-1-duoming@zju.edu.cn Signed-off-by: John Paul Adrian Glaubitz [ Backport to 6.1.y: use timer_shutdown_sync(), already available here, so the timer cannot rearm before the queued work is flushed. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 9079ef5fb26ff38ced50cc15199ce56a009b8605 Author: Jianbo Liu Date: Thu Sep 24 13:35:04 2026 -0400 net/mlx5e: TC, Fix internal port memory leak [ Upstream commit ac5da544a3c2047cbfd715acd9cec8380d7fe5c6 ] The flow rule can be splited, and the extra post_act rules are added to post_act table. It's possible to trigger memleak when the rule forwards packets from internal port and over tunnel, in the case that, for example, CT 'new' state offload is allowed. As int_port object is assigned to the flow attribute of post_act rule, and its refcnt is incremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() is not called, the refcnt is never decremented, then int_port is never freed. The kmemleak reports the following error: unreferenced object 0xffff888128204b80 (size 64): comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s) hex dump (first 32 bytes): 01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00 ................ 98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff .wgA.....wgA.... backtrace: [<00000000e992680d>] kmalloc_trace+0x27/0x120 [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core] [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core] [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core] [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core] [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core] [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core] [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410 [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower] [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower] [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010 [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0 [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360 [<0000000082dd6c8b>] netlink_unicast+0x438/0x710 [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50 [<0000000016e92590>] sock_sendmsg+0xc5/0x190 So fix this by moving int_port cleanup code to the flow attribute free helper, which is used by all the attribute free cases. Fixes: 8300f225268b ("net/mlx5e: Create new flow attr for multi table actions") Signed-off-by: Jianbo Liu Reviewed-by: Vlad Buslov Signed-off-by: Saeed Mahameed [ Backport to 6.1.y: this tree already releases the primary flow-attribute references in mlx5e_tc_del_fdb_flow() and lacks mlx5_free_flow_attr_actions(); release only cloned post-action attribute references from the corresponding free_flow_post_acts() cleanup. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit bca783c943cefea97c27f02fdd16bf414e8057df Author: Hans de Goede Date: Thu Sep 24 13:33:12 2026 -0400 media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings [ Upstream commit 284be5693163343e1cf17c03917eecd1d6681bcf ] When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run sensor->adev is not set yet. So if either of the dev_warn() calls about unknown values are hit this will lead to a NULL pointer deref. Set sensor->adev earlier, with a borrowed ref to avoid making unrolling on errors harder, to fix this. Fixes: 485aa3df0dff ("media: ipu3-cio2: Parse sensor orientation and rotation") Cc: Fabian Wüthrich Signed-off-by: Hans de Goede Reviewed-by: Daniel Scally Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [ Backport to 6.1.y: apply the sensor adev assignment in this tree's older ipu3/cio2-bridge.c and cio2_bridge_connect_sensor(). ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 5a7e8f89cdee16db705905a5b1ce2100b13dd63e Author: ndesaulniers@google.com Date: Thu Sep 24 13:30:59 2026 -0400 start_kernel: Add __no_stack_protector function attribute [ Upstream commit 514ca14ed5444b911de59ed3381dfd195d99fe4b ] Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it. Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722 Link: https://lore.kernel.org/all/20200316130414.GC12561@hirez.programming.kicks-ass.net/ Tested-by: Nathan Chancellor Acked-by: Michael Ellerman (powerpc) Acked-by: Miguel Ojeda Acked-by: Peter Zijlstra (Intel) Signed-off-by: Nick Desaulniers Link: https://lore.kernel.org/r/20230412-no_stackp-v2-1-116f9fe4bbe7@google.com Signed-off-by: Josh Poimboeuf Signed-off-by: ndesaulniers@google.com [ Backport to 6.1.y: retain this tree's start_kernel() signature, which predates its upstream __noreturn annotation, and add __no_stack_protector. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit a216f6dc0444c3bd900bca66b9f21467d08e3ed3 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 [ 6.1: context adjusted only - mousevsc_ll_driver is non-const in 6.1 because the hid_ll_driver constification (for-6.12/constify-rdesc, e.g. 054e0bd34577) 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 f130b2f545a25a59adb1d293c215a36b4e129d92 Author: Martin KaFai Lau Date: Fri Sep 1 16:11:28 2023 -0700 bpf: bpf_sk_storage: Fix the missing uncharge in sk_omem_alloc [ Upstream commit 55d49f750b1cb1f177fb1b00ae02cba4613bcfb7 ] The commit c83597fa5dc6 ("bpf: Refactor some inode/task/sk storage functions for reuse"), refactored the bpf_{sk,task,inode}_storage_free() into bpf_local_storage_unlink_nolock() which then later renamed to bpf_local_storage_destroy(). The commit accidentally passed the "bool uncharge_mem = false" argument to bpf_selem_unlink_storage_nolock() which then stopped the uncharge from happening to the sk->sk_omem_alloc. This missing uncharge only happens when the sk is going away (during __sk_destruct). This patch fixes it by always passing "uncharge_mem = true". It is a noop to the task/inode/cgroup storage because they do not have the map_local_storage_(un)charge enabled in the map_ops. A followup patch will be done in bpf-next to remove the uncharge_mem argument. A selftest is added in the next patch. Fixes: c83597fa5dc6 ("bpf: Refactor some inode/task/sk storage functions for reuse") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20230901231129.578493-3-martin.lau@linux.dev Signed-off-by: Sasha Levin commit 5cfd415214adfce5595c73d1a1d924e70367307e 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 be7929770a783b983583a5f9aeebd3facd688ed2 Author: Junli Liu Date: Tue Aug 5 09:19:58 2025 +0800 erofs: fix atomic context detection when !CONFIG_DEBUG_LOCK_ALLOC [ Upstream commit c99fab6e80b76422741d34aafc2f930a482afbdd ] Since EROFS handles decompression in non-atomic contexts due to uncontrollable decompression latencies and vmap() usage, it tries to detect atomic contexts and only kicks off a kworker on demand in order to reduce unnecessary scheduling overhead. However, the current approach is insufficient and can lead to sleeping function calls in invalid contexts, causing kernel warnings and potential system instability. See the stacktrace [1] and previous discussion [2]. The current implementation only checks rcu_read_lock_any_held(), which behaves inconsistently across different kernel configurations: - When CONFIG_DEBUG_LOCK_ALLOC is enabled: correctly detects RCU critical sections by checking rcu_lock_map - When CONFIG_DEBUG_LOCK_ALLOC is disabled: compiles to "!preemptible()", which only checks preempt_count and misses RCU critical sections This patch introduces z_erofs_in_atomic() to provide comprehensive atomic context detection: 1. Check RCU preemption depth when CONFIG_PREEMPTION is enabled, as RCU critical sections may not affect preempt_count but still require atomic handling 2. Always use async processing when CONFIG_PREEMPT_COUNT is disabled, as preemption state cannot be reliably determined 3. Fall back to standard preemptible() check for remaining cases The function replaces the previous complex condition check and ensures that z_erofs always uses (kthread_)work in atomic contexts to minimize scheduling overhead and prevent sleeping in invalid contexts. [1] Problem stacktrace [ 61.266692] BUG: sleeping function called from invalid context at kernel/locking/rtmutex_api.c:510 [ 61.266702] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 107, name: irq/54-ufshcd [ 61.266704] preempt_count: 0, expected: 0 [ 61.266705] RCU nest depth: 2, expected: 0 [ 61.266710] CPU: 0 UID: 0 PID: 107 Comm: irq/54-ufshcd Tainted: G W O 6.12.17 #1 [ 61.266714] Tainted: [W]=WARN, [O]=OOT_MODULE [ 61.266715] Hardware name: schumacher (DT) [ 61.266717] Call trace: [ 61.266718] dump_backtrace+0x9c/0x100 [ 61.266727] show_stack+0x20/0x38 [ 61.266728] dump_stack_lvl+0x78/0x90 [ 61.266734] dump_stack+0x18/0x28 [ 61.266736] __might_resched+0x11c/0x180 [ 61.266743] __might_sleep+0x64/0xc8 [ 61.266745] mutex_lock+0x2c/0xc0 [ 61.266748] z_erofs_decompress_queue+0xe8/0x978 [ 61.266753] z_erofs_decompress_kickoff+0xa8/0x190 [ 61.266756] z_erofs_endio+0x168/0x288 [ 61.266758] bio_endio+0x160/0x218 [ 61.266762] blk_update_request+0x244/0x458 [ 61.266766] scsi_end_request+0x38/0x278 [ 61.266770] scsi_io_completion+0x4c/0x600 [ 61.266772] scsi_finish_command+0xc8/0xe8 [ 61.266775] scsi_complete+0x88/0x148 [ 61.266777] blk_mq_complete_request+0x3c/0x58 [ 61.266780] scsi_done_internal+0xcc/0x158 [ 61.266782] scsi_done+0x1c/0x30 [ 61.266783] ufshcd_compl_one_cqe+0x12c/0x438 [ 61.266786] __ufshcd_transfer_req_compl+0x2c/0x78 [ 61.266788] ufshcd_poll+0xf4/0x210 [ 61.266789] ufshcd_transfer_req_compl+0x50/0x88 [ 61.266791] ufshcd_intr+0x21c/0x7c8 [ 61.266792] irq_forced_thread_fn+0x44/0xd8 [ 61.266796] irq_thread+0x1a4/0x358 [ 61.266799] kthread+0x12c/0x138 [ 61.266802] ret_from_fork+0x10/0x20 [2] https://lore.kernel.org/r/58b661d0-0ebb-4b45-a10d-c5927fb791cd@paulmck-laptop Signed-off-by: Junli Liu Reviewed-by: Gao Xiang Link: https://lore.kernel.org/r/20250805011957.911186-1-liujunli@lixiang.com [ Gao Xiang: Use the original trace in v1. ] Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 209aeac6b45b9057578f341d0c0a2f73f8f795e9 Author: Mickaël Salaün Date: Wed Sep 23 15:22:47 2026 +0200 selftests/landlock: Add layout1.refer_mount_root [ Upstream commit 0055f53aac80fd938bf7cdfad7ad414ca6c0e198 ] Add tests to check error codes when linking or renaming a mount root directory. This previously triggered a kernel warning, but it is fixed with the previous commit. Cc: Günther Noack Cc: Paul Moore Link: https://lore.kernel.org/r/20240516181935.1645983-3-mic@digikod.net Signed-off-by: Mickaël Salaün [mic: Backport: adapt to the older selftest header layout] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 96bcd9650e15901201d964eef5f79d18a81daac8 Author: Sandeep Dhavale Date: Tue Sep 22 16:04:36 2026 -0400 erofs: Fix detection of atomic context [ Upstream commit 12d0a24afd9ea58e581ea64d64e066f2027b28d9 ] Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/ Reported-by: Will Shiu Suggested-by: Gao Xiang Signed-off-by: Sandeep Dhavale Reviewed-by: Gao Xiang Reviewed-by: Alexandre Mergnat Link: https://lore.kernel.org/r/20230621220848.3379029-1-dhavale@google.com Signed-off-by: Gao Xiang [ Backport to 6.1.y: the source change is unchanged; only its location in z_erofs_decompress_kickoff() differs. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit ff1338a3bfaa2f35b5f49a434f2ad6884b75fafe Author: Bjorn Andersson Date: Tue Sep 22 16:01:26 2026 -0400 drm/msm/dp: Drop aux devices together with DP controller [ Upstream commit a7bfb2ad2184a1fba78be35209b6019aa8cc8d4d ] Using devres to depopulate the aux bus made sure that upon a probe deferral the EDP panel device would be destroyed and recreated upon next attempt. But the struct device which the devres is tied to is the DPUs (drm_dev->dev), which may be happen after the DP controller is torn down. Indications of this can be seen in the commonly seen EDID-hexdump full of zeros in the log, or the occasional/rare KASAN fault where the panel's attempt to read the EDID information causes a use after free on DP resources. It's tempting to move the devres to the DP controller's struct device, but the resources used by the device(s) on the aux bus are explicitly torn down in the error path. The KASAN-reported use-after-free also remains, as the DP aux "module" explicitly frees its devres-allocated memory in this code path. As such, explicitly depopulate the aux bus in the error path, and in the component unbind path, to avoid these issues. Fixes: 2b57f726611e ("drm/msm/dp: fix aux-bus EP lifetime") Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Patchwork: https://patchwork.freedesktop.org/patch/542163/ Link: https://lore.kernel.org/r/20230612220106.1884039-1-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov [ Backport to 6.1.y: the source change is unchanged; refresh context around the older DP bridge layout. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 47cf3387de902e8f61f705b06cb2fc1315d26932 Author: Martin KaFai Lau Date: Tue Sep 22 15:55:38 2026 -0400 bpf: bpf_sk_storage: Fix invalid wait context lockdep report [ Upstream commit a96a44aba556c42b432929d37d60158aca21ad4c ] './test_progs -t test_local_storage' reported a splat: [ 27.137569] ============================= [ 27.138122] [ BUG: Invalid wait context ] [ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O [ 27.139542] ----------------------------- [ 27.140106] test_progs/1729 is trying to lock: [ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130 [ 27.141834] other info that might help us debug this: [ 27.142437] context-{5:5} [ 27.142856] 2 locks held by test_progs/1729: [ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40 [ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0 [ 27.145855] stack backtrace: [ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247 [ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 27.149127] Call Trace: [ 27.149490] [ 27.149867] dump_stack_lvl+0x130/0x1d0 [ 27.152609] dump_stack+0x14/0x20 [ 27.153131] __lock_acquire+0x1657/0x2220 [ 27.153677] lock_acquire+0x1b8/0x510 [ 27.157908] local_lock_acquire+0x29/0x130 [ 27.159048] obj_cgroup_charge+0xf4/0x3c0 [ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0 [ 27.161931] __kmem_cache_alloc_node+0x51/0x210 [ 27.163557] __kmalloc+0xaa/0x210 [ 27.164593] bpf_map_kzalloc+0xbc/0x170 [ 27.165147] bpf_selem_alloc+0x130/0x510 [ 27.166295] bpf_local_storage_update+0x5aa/0x8e0 [ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0 [ 27.169199] bpf_map_update_value+0x415/0x4f0 [ 27.169871] map_update_elem+0x413/0x550 [ 27.170330] __sys_bpf+0x5e9/0x640 [ 27.174065] __x64_sys_bpf+0x80/0x90 [ 27.174568] do_syscall_64+0x48/0xa0 [ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 27.175932] RIP: 0033:0x7effb40e41ad [ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d8 [ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141 [ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad [ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002 [ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788 [ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000 [ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000 [ 27.184958] It complains about acquiring a local_lock while holding a raw_spin_lock. It means it should not allocate memory while holding a raw_spin_lock since it is not safe for RT. raw_spin_lock is needed because bpf_local_storage supports tracing context. In particular for task local storage, it is easy to get a "current" task PTR_TO_BTF_ID in tracing bpf prog. However, task (and cgroup) local storage has already been moved to bpf mem allocator which can be used after raw_spin_lock. The splat is for the sk storage. For sk (and inode) storage, it has not been moved to bpf mem allocator. Using raw_spin_lock or not, kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context. However, the local storage helper requires a verifier accepted sk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean running a bpf prog in a kzalloc unsafe context and also able to hold a verifier accepted sk pointer) could happen. This patch avoids kzalloc after raw_spin_lock to silent the splat. There is an existing kzalloc before the raw_spin_lock. At that point, a kzalloc is very likely required because a lookup has just been done before. Thus, this patch always does the kzalloc before acquiring the raw_spin_lock and remove the later kzalloc usage after the raw_spin_lock. After this change, it will have a charge and then uncharge during the syscall bpf_map_update_elem() code path. This patch opts for simplicity and not continue the old optimization to save one charge and uncharge. This issue is dated back to the very first commit of bpf_sk_storage which had been refactored multiple times to create task, inode, and cgroup storage. This patch uses a Fixes tag with a more recent commit that should be easier to do backport. Fixes: b00fa38a9c1c ("bpf: Enable non-atomic allocations in local storage") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20230901231129.578493-2-martin.lau@linux.dev [ Backport to 6.1.y: retain the pre-reuse_now unlink/free API while moving the charged element allocation outside local_storage->lock. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit a7860bb0dafa9138c8c38690f1c3313c0c19f61e Author: Itai Handler Date: Tue Sep 22 17:02:38 2026 +0300 spi: spi-zynqmp-gqspi: stop the controller on shutdown commit e922bad8b2d5028c51a096d083fea41cd0987154 upstream. The driver has no ->shutdown, and platform_drv_shutdown() has no fallback of its own. Unlike pci_device_shutdown(), which clears bus mastering when kexec_in_progress, nothing on the platform bus disarms a device that can still write to memory. The normal kexec path never calls ->suspend either, so the quiesce in zynqmp_qspi_suspend() is not reached. A controller that is still executing a DMA read may therefore keep writing to memory across a kexec. QSPIDMA_DST_ADDR still points at memory owned by the kernel that called kexec, DST_SIZE is non-zero and the flash is still clocked, so data can keep landing in RAM while the new kernel is being relocated, and after it has started executing. That destination is a physical address which means nothing to the new kernel, so the writes can corrupt whatever now occupies it: kernel text or data, page tables, or the initrd. Nothing reports an error and the resulting behaviour is undefined. This can be observed by reading GQSPI_EN (offset 0x114) and QSPIDMA_DST_ADDR/SIZE/STS/CTRL (offsets 0x800 to 0x80c) early in the new kernel, before the driver probes: without this patch GQSPI_EN reads 1 and QSPIDMA_DST_ADDR still points into the previous kernel's memory. Add a ->shutdown that stops the controller the way zynqmp_qspi_suspend() already does. spi_controller_suspend() stops the queue, waits for a message that is already executing and makes any later transfer fail with -ESHUTDOWN, so nothing can be cut short by the register write that follows. It may sleep, which is fine here: device_shutdown() runs in process context. Unlike ->suspend this cannot abort on error, because a controller left mastering the bus is worse than a truncated transfer, so a failure to drain is only logged. GQSPI_EN_OFST is then cleared, as zynqmp_qspi_remove() and zynqmp_qspi_suspend() already do. Skip that write only when pm_runtime_get_if_in_use() returns 0, i.e. runtime suspended: the clocks are gated, so the registers are unreachable and the controller cannot be mastering the bus. A negative return is not the same thing - it is what the CONFIG_PM=n stub always returns, and there probe() has enabled pclk and refclk for good, so the controller is running and must be stopped. Fixes: dfe11a11d523 ("spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Itai Handler Link: https://patch.msgid.link/20260910174832.873352-1-itai.handler@gmail.com Signed-off-by: Mark Brown [ itai: context only - zynqmp_qspi_of_match[] still sits between zynqmp_qspi_remove() and MODULE_DEVICE_TABLE() in this tree, hoisted to the top of the file upstream by commit 29f4d95b97bc ("spi: spi-zynqmp-gqspi: Add tap delay support for GQSPI controller on Versal platform"), so zynqmp_qspi_shutdown() is placed above it ] Signed-off-by: Itai Handler Signed-off-by: Sasha Levin commit 291f8b8b312a84e748b8d907a7a88408844087f8 Author: Chen Xiaokun Date: Wed Sep 23 14:43:15 2026 +0800 io_uring/io-wq: Fix memory leak in io_wq_create() on success path [ This is a stable-only patch for 6.1.y ] Commit 657ca82526d0 ("io_uring/io-wq: inherit cpuset of cgroup in io worker") was backported from upstream commit 84eacf177faa to 6.1.y. In linux-6.1.y, this backport introduced a temporary allowed_mask variable in io_wq_create(). It is correctly freed on the error path, but is not freed on the success path. As a result, every successful call to io_wq_create() leaks cpumask_size() bytes of memory. This is a 6.1-specific backport issue caused by the differences in the io-wq implementation, so the fix only applies to 6.1.y. Fixes: 657ca82526d0 ("io_uring/io-wq: inherit cpuset of cgroup in io worker") Signed-off-by: Chen Xiaokun Signed-off-by: Sasha Levin commit 3c26023365a955d2d69355f5167508a963e44333 Author: Christoph Hellwig Date: Tue Sep 22 15:58:35 2026 -0400 btrfs: don't check PageError in __extent_writepage [ Upstream commit 3e92499e3b004baffb479d61e191b41b604ece9a ] __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context. Reviewed-by: Josef Bacik Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba Signed-off-by: David Sterba [ Backport to 6.1.y: apply the PageError-to-ret change in this tree's pre-btrfs_bio_ctrl __extent_writepage(). ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit e07d4e2512f66221b09e2190be88f4183ba30ea4 Author: Pauli Virtanen Date: Tue Sep 22 15:48:34 2026 -0400 Bluetooth: hci_sync: always check if connection is alive before deleting [ Upstream commit a239110ee8e0b0aafa265f0d54f7a16744855e70 ] In hci_abort_conn_sync it is possible that conn is deleted concurrently by something else, also e.g. when waiting for hdev->lock. This causes double deletion of the conn, so UAF or conn_hash.list corruption. Fix by having all code paths check that the connection is still in conn_hash before deleting it, while holding hdev->lock which prevents any races. Log (when powering off while BAP streaming, occurs rarely): ======================================================================= kernel BUG at lib/list_debug.c:56! ... ? __list_del_entry_valid (lib/list_debug.c:56) hci_conn_del (net/bluetooth/hci_conn.c:154) bluetooth hci_abort_conn_sync (net/bluetooth/hci_sync.c:5415) bluetooth ? __pfx_hci_abort_conn_sync+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? hci_disconnect_all_sync.constprop.0+0xb2/0x230 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __kmem_cache_free+0x14d/0x2e0 hci_disconnect_all_sync.constprop.0+0xda/0x230 [bluetooth] ? __pfx_hci_disconnect_all_sync.constprop.0+0x10/0x10 [bluetooth] ? hci_clear_adv_sync+0x14f/0x170 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x293/0x450 [bluetooth] ======================================================================= Fixes: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz [ Backport to 6.1.y follow-up to 94d9ba9f9888: this tree lacks the later BT_OPEN and BT_BOUND special cases, so retain its existing state switch and add the common liveness check. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 5e3ee972f185eb7957ce789b3bf13a3cb790f178 Author: Luiz Augusto von Dentz Date: Tue Sep 22 15:48:33 2026 -0400 Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync [ Upstream commit 94d9ba9f9888b748d4abd2aa1547af56ae85f772 ] Use-after-free can occur in hci_disconnect_all_sync if a connection is deleted by concurrent processing of a controller event. To prevent this the code now tries to iterate over the list backwards to ensure the links are cleanup before its parents, also it no longer relies on a cursor, instead it always uses the last element since hci_abort_conn_sync is guaranteed to call hci_conn_del. UAF crash log: ================================================================== BUG: KASAN: slab-use-after-free in hci_set_powered_sync (net/bluetooth/hci_sync.c:5424) [bluetooth] Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124 CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W 6.5.0-rc1+ #10 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xdd/0x160 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] kasan_report+0xa6/0xe0 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_cmd_sync_work+0x137/0x220 [bluetooth] process_one_work+0x526/0x9d0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x1a/0x90 worker_thread+0x92/0x630 ? __pfx_worker_thread+0x10/0x10 kthread+0x196/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 Allocated by task 1782: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 hci_conn_add+0xa5/0xa80 [bluetooth] hci_bind_cis+0x881/0x9b0 [bluetooth] iso_connect_cis+0x121/0x520 [bluetooth] iso_sock_connect+0x3f6/0x790 [bluetooth] __sys_connect+0x109/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 695: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10a/0x180 __kmem_cache_free+0x14d/0x2e0 device_release+0x5d/0xf0 kobject_put+0xdf/0x270 hci_disconn_complete_evt+0x274/0x3a0 [bluetooth] hci_event_packet+0x579/0x7e0 [bluetooth] hci_rx_work+0x287/0xaa0 [bluetooth] process_one_work+0x526/0x9d0 worker_thread+0x92/0x630 kthread+0x196/0x1e0 ret_from_fork+0x2c/0x50 ================================================================== Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz [ Backport to 6.1.y: the source change is unchanged; only hunk locations in hci_sync.c differ. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 54142217cc8146d2979e1fa1ca3fc3987dc6204e Author: Chengming Zhou Date: Mon Sep 21 16:07:26 2026 -0400 blk-mq: fix tags UAF when shrinking q->nr_hw_queues [ Upstream commit 6be6d112419713334ddd9c01f219ca16adaa4c76 ] When nr_hw_queues shrink, we free the excess tags before realloc'ing hw_ctxs for each queue. During that resize, we may need to access those tags, like blk_mq_tag_idle(hctx) will access queue shared tags. This can cause a slab use-after-free, as reported by KASAN. Fix it by moving the releasing of excess tags to the end. Fixes: e1dd7bc93029 ("blk-mq: fix tags leak when shrink nr_hw_queues") Reported-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs_CK63uoDpGBGZ6DN4OCTpzkR3UaVgK=LX8Owr8ej2ieQ@mail.gmail.com/ Cc: Ming Lei Signed-off-by: Chengming Zhou Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20230908005702.2183908-1-chengming.zhou@linux.dev Signed-off-by: Jens Axboe [ Backport to 6.1.y follow-up to e1dd7bc93029: move those frees after hctx resizing using cur_nr_hw_queues, preventing its tag UAF. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 26d495f0f64d8cd4fcd29206ee5c653ee0e0cbcd Author: Chengming Zhou Date: Mon Sep 21 16:07:25 2026 -0400 blk-mq: fix tags leak when shrink nr_hw_queues [ Upstream commit e1dd7bc93029024af5688253b0c05181d6e01f8e ] Although we don't need to realloc set->tags[] when shrink nr_hw_queues, we need to free them. Or these tags will be leaked. How to reproduce: 1. mount -t configfs configfs /mnt 2. modprobe null_blk nr_devices=0 submit_queues=8 3. mkdir /mnt/nullb/nullb0 4. echo 1 > /mnt/nullb/nullb0/power 5. echo 4 > /mnt/nullb/nullb0/submit_queues 6. rmdir /mnt/nullb/nullb0 In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), then in step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue). At last in step 6, only these 5 tags are freed, the other 4 tags leaked. Signed-off-by: Chengming Zhou Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20230821095602.70742-1-chengming.zhou@linux.dev Signed-off-by: Jens Axboe [ Backport to 6.1.y: use this tree's cur_nr_hw_queues snapshot when freeing excess tag sets. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit f427383e734e95af923ac470782ad9a3d1f0c276 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 f2293a9614fbe05fe4e5435bd0ebb0c32740e92d Author: Peter Ujfalusi Date: Mon Sep 21 15:37:48 2026 -0400 ASoC: SOF: ipc4-topology: Clarify bind failure caused by missing fw_module [ Upstream commit de6aa72b265b72bca2b1897d5000c8f0147d3157 ] The original patch uses a feature in lib/vsprintf.c to handle the invalid address when tring to print *_fw_module->man4_module_entry.name when the *rc_fw_module is NULL. This case is handled by check_pointer_msg() internally and turns the invalid pointer to '(efault)' for printing but it is hiding useful information about the circumstances. Change the print to emmit the name of the widget and a note on which side's fw_module is missing. Fixes: e3720f92e023 ("ASoC: SOF: avoid a NULL dereference with unsupported widgets") Reported-by: Dan Carpenter Link: https://lore.kernel.org/alsa-devel/4826f662-42f0-4a82-ba32-8bf5f8a03256@kili.mountain/ Signed-off-by: Peter Ujfalusi Rule: 'Cc: stable@vger.kernel.org' or 'commit upstream.' Link: https://lore.kernel.org/r/20230403090909.18233-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown [ Backport to 6.1.y follow-up to e3720f92e023: replace its (efault) pointer formatting with source/sink diagnostics; only hunk locations differ. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit d42fe2721111138d7656d4f621f38c171979c8a0 Author: Guennadi Liakhovetski Date: Mon Sep 21 15:37:47 2026 -0400 ASoC: SOF: avoid a NULL dereference with unsupported widgets [ Upstream commit e3720f92e0237921da537e47a0b24e27899203f8 ] If an IPC4 topology contains an unsupported widget, its .module_info field won't be set, then sof_ipc4_route_setup() will cause a kernel Oops trying to dereference it. Add a check for such cases. Cc: stable@vger.kernel.org # 6.2 Signed-off-by: Guennadi Liakhovetski Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20230329113828.28562-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown [ Backport to 6.1.y: although the upstream stable tag names 6.2, the same module_info dereference is present here; the source change is otherwise unchanged. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 77d9b2a3937797eaff72968cc9c88e6748998823 Author: Frank Sorenson Date: Wed Sep 16 16:33:55 2026 -0500 smb: client: fix missing lower-bound check on DFS referral string offsets commit e83330c55edc0c3ac08aa6c95e49e4694c65523b upstream. parse_dfs_referrals() checks that DfsPathOffset and NetworkAddressOffset do not exceed the buffer end, but fails to check that they don't point inside the referral header itself. If a server provides an offset smaller than sizeof(struct dfs_referral_level_3), the derived string pointer overlaps with the struct fields, causing cifs_strndup_from_utf16() to interpret header data as UTF-16 strings. Fix this by enforcing that string offsets are at least sizeof(*ref). Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 8703539d22fdbc13dd2db090ee199c3a427b8ea0 Author: Frank Sorenson Date: Wed Sep 16 16:33:54 2026 -0500 smb: client: fix server->total_read for compound encrypted PDUs commit f73726b83e4756fdaa099e1bc1143293bd57ad79 upstream. In receive_encrypted_standard(), server->total_read is left at the full decrypted frame size when walking sub-PDUs of a compound encrypted frame. As a result, cifs_handle_standard() passes this full size to smb2_check_message(), causing the PDU length guards to incorrectly validate the entire compound frame instead of the current sub-PDU. This allows truncated non-last sub-PDUs to bypass length validation, leading to out-of-bounds reads in smb2_get_data_area_len(). Fix this by setting server->total_read to the true length of the current sub-PDU: next_cmd for non-last sub-PDUs, and the remaining pdu_length for the last one. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 15a221c734b9d044ab769e7e3606b2cab96fb65a Author: Frank Sorenson Date: Wed Sep 16 16:33:59 2026 -0500 smb: client: fix potential OOB read in smb3_enum_snapshots() commit 4775c3b7a597907e0b97556c7986fda238a377ae upstream. If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply. Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len. Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read. Fixes: e02789a53d71 ("smb3: enumerating snapshots was leaving part of the data off end") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 72eaef1f37a3b6bec11c342736834dc3707be3e4 Author: Frank Sorenson Date: Wed Sep 16 16:33:52 2026 -0500 smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs commit 05762c5bc1cfdcac36747994fde2c04387a457f1 upstream. Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: - Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. - Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. - Reject next_cmd values smaller than MID_HEADER_SIZE(server). - Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 3164402c58940ff58a3cecdb026405f07b0253af Author: Paulo Alcantara Date: Sat Sep 12 14:20:08 2026 -0300 smb: client: fix smbd_connection leak on cifs_get_tcp_session() error commit e75c96157d45e498970158c8f7373d90102e33b9 upstream. When an RDMA connection is successfully established via smbd_get_connection() but cifs_get_tcp_session() later fails (e.g. kthread_create() returns an error), the error path frees tcp_ses without first destroying the smbd_connection. Fix this by calling smbd_destroy() in the out_err cleanup path before kfree(tcp_ses). smbd_destroy() safely handles the case where smbd_conn is NULL, so it can be called unconditionally. Closes: https://sashiko.dev/#/patchset/20260912165503.521597-1-pc%40manguebit.org Fixes: 2f8946464b11 ("CIFS: SMBD: Upper layer connects to SMBDirect session") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Tom Talpey Cc: Stefan Metzmacher Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 80c27358bafef3677a8a5d49602e135c15ece101 Author: Frank Sorenson Date: Wed Sep 16 16:33:56 2026 -0500 smb: client: reject short Next offsets in parse_server_interfaces() commit 1b3221bb121079ad79a1f3c3aa360ba649832e7a upstream. In parse_server_interfaces(), the server-supplied Next offset is validated against bytes_left, but not against the size of the interface structure itself. A small, non-zero Next value can pass the bounds check but advance the pointer by less than sizeof(*p). This causes the next iteration of the loop to read misaligned, overlapping structure fields. Fix this by ensuring the Next offset is at least sizeof(*p). Fixes: 7d34ec36abb8 ("smb3: fix for slab out of bounds on mount to ksmbd") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 64c28938704f2f26c8e14297cbfd5a1096a1a429 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 80d3129c0a82f6f9cfb21744d9c01491a48a1027 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 4153a9e008f2512bd3cf90a319436865847369b9 Author: Sajal Gupta Date: Wed Sep 2 18:00:57 2026 +0530 drm/gud: fix out-of-bounds write in gud_plane_atomic_check() commit 59ced288fcba9e91bd38e61a972ad782c4edb7d0 upstream. The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing `num_properties` inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at `initial_num_properties + 2*i`, skipping every other index and advancing by 2 per iteration. With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties. Fix by dropping the redundant `+ i`; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260821071812.16500-1-sajal2005gupta%40gmail.com?part=1 Signed-off-by: Sajal Gupta Cc: Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260902123254.36987-1-sajal2005gupta@gmail.com Signed-off-by: Greg Kroah-Hartman commit c2cd9c44777cf97be3e35c10b7c2d8f59ebb9306 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 212c8332b4583a5f2c36052b1f00b50a0ede88aa 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 dccf5ecaad4d8d43c545921f20328e8f91af8698 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 58767b41f87244eebaa5a475b9d276c83b89b933 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 487f966421014de41e835bbce3feb30b35f4f729 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 03d313e3dfb49a44c10a5c423452967694fb85e2 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 aeb44a456d126d89863230eef0187e77e6441995 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 a5b827dad8a3037cef04d0240d1c2acb1557101e 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 c02352e2b5a241c8da89b5f5f1a0ae4d403120ed 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 62d40db89180cfab7a917395f9ffc1dac62b0019 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 b4745d6063758c681d33affca9733bbd356b6ea1 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 c9a116d691364cd7f59d8329b395adcaf826d5c6 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 050d2486e8ed2c0a23b87249ccd23e8072721391 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 c0e1535388187074fc96bfc72622bb19144a2ff4 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 a5906f477b5f6dc475d11fe8aa750d04936d5ff5 Author: Tzung-Bi Shih Date: Sun Sep 13 00:33:34 2026 +0800 watchdog: msc313e: Propagate error code in resume() commit 1d9763f34a85680db1e8233d654fdb85e5f897cc upstream. If msc313e_wdt_start() fails during system resume, the error is currently ignored. Consequently, the watchdog isn't running without the user's knowledge. Propagate the error code and print a message if msc313e_wdt_start() fails. Signed-off-by: Tzung-Bi Shih Fixes: e9800b7994642 ("watchdog: Add Mstar MSC313e WDT driver") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260912163334.28636-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 2989fc756a22ed98b8c5560351a701378b7b0615 Author: Tzung-Bi Shih Date: Sun Sep 13 14:51:26 2026 +0800 watchdog: msc313e: Fix premature reset during timeout update commit 22737cfced627ffcb4b5c36d63bb3d4476f63213 upstream. Updating the 32-bit hardware timeout requires writing to two 16-bit registers sequentially. If the watchdog is actively running, this non-atomic update might trigger a premature system reset. Clear the watchdog counter before updating the registers to prevent the timer from timing out prematurely against an intermediate threshold. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913065126.8350-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit e57a99184a126a609dc237f4c352a7518ff4c957 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 95adc37f47cdf5a5285f7163b24243680af510be Author: Li Jun Date: Thu Sep 17 09:37:10 2026 +0800 watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog commit 7cb575b71ab98194d2e040bded3a7281e089c5ed upstream. da9063_wdt_suspend() and da9063_wdt_resume() only check watchdog_active(), when the watchdog is left running by the driver sets WDOG_HW_RUNNING in da9063_wdt_probe() but userspace never opens the device, so WDOG_ACTIVE remains cleared, the wdt_disable() will not be executed in da9063_wdt_suspend. In this case, the suspend callback is a no-op and the watchdog keeps counting during system suspend, leading to an unexpected system reset. Check WDOG_HW_RUNNING and wdd，can fix this issue. Fixes: a7ceca4398bc8 ("watchdog: da9063: optionally disable watchdog during suspend") Cc: stable@vger.kernel.org Signed-off-by: Li Jun Link: https://patch.msgid.link/20260917013710.2754679-1-lijun01@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 2202b7356d17546d5b7b3871d20b45aa8921b431 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 2ccf6c512290a288a2d4d7f076430dfb0c6ee476 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 be916f66771ee5fc614eb997be2fdd507296570f Author: Sanman Pradhan Date: Wed Sep 16 23:54:17 2026 +0000 hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676 commit 089070b51ccbac411462a30a454690274c6e4270 upstream. tps53676_identify() derives the number of PMBus pages but does not ensure that page 0 is selected for single-page configurations. pmbus_set_page() does not update the PAGE register when info->pages is 1, so if boot firmware leaves PAGE set to another value subsequent register accesses may target the wrong page. For single-page devices, select page 0 explicitly. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://patch.msgid.link/20260916235406.681131-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8a5703fce397587c319fac121e3e07aae9251c25 Author: Sanman Pradhan Date: Tue Sep 15 16:48:35 2026 +0000 hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding commit 1d12fb94ac0975566545871dda100df34df5f845 upstream. tps53676_identify() reads the USER_DATA_03 phase configuration to count the phases assigned to each channel and derive the number of PMBus pages. In each 16-bit phase descriptor the channel (PAGE) is encoded in bit 4 and the firing order in bits 3:0, but the code tested bit 3 (0x08), which is part of the firing-order field. TPS53676 supports up to seven phases, so firing-order bit 3 is never set. As a result the existing test classifies every enabled phase as channel A. On a dual-channel configuration the phases assigned to channel B are therefore miscounted as channel A and page 1 is not exposed. Test the PAGE field (bit 4) instead. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://patch.msgid.link/20260915164823.160977-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b32607710a20ad983f9fe4a3051892584c0641a4 Author: Nuno Sá Date: Fri Sep 11 14:53:37 2026 +0100 hwmon: (pmbus/core) increase number of phases and add new mask commit 06bd6794b5fd2163880ac3bfe973d4cc61f359f3 upstream. Increase the number of phases to 16 as a new upcoming device supports such a number. While at it, add a new mask for controlling the source of the output voltage. Note (groeck): This patch was meant to prepare for support of MAX20826 and compatible devices, which support more than 10 phases per page. However, Sashiko reports that the mp2975 driver already supports up to 14 phases, and the mp2856 driver supports up to 12 phases. This already has the potential for out-of-bounds writes when probing the affected chips, making this patch a bug fix. Fixes: 2c6fcbb21149 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Fixes: f9e5f289b686 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2856/mp2857 controller") Signed-off-by: Nuno Sá Link: https://patch.msgid.link/20260911-hwmon-max20826-support-v2-1-5e30cbd97d84@analog.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6c26681c5668c973bd0e951407d670ac60d9cd66 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 84145a4a1dc58f8959811913c5f61f3235dd9f6c 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 6b0ecd26cb17bb56be8a5e9290305a89ccea9791 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 c62c6944c680bc4ae188ca9045daada32fcd10ec 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 f025d2f0bd177aaaca40add3eca5ac06b01cb042 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 29fbcf5834f0a7f74bfd017c07da2411b35a4e2a 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 70f0dde6aa027e0a5fa1173ea166bc8d62481a68 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 e834e134a32b6a5c600fa539bb49146f617743ab 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 8d3852c3aaef79164a8f1e1af851fff4ad15a9e8 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 da60a43d85dd7d37acf40b4054559920adf0e7f5 Author: Alvin Šipraga Date: Tue Aug 18 18:00:02 2026 +0200 Input: adp5588-keys - cache GPIO state before registering the gpiochip commit 21efadc62272cabee9bec27777ae75d84a9ca8a8 upstream. So as not to clobber any pre-programmed GPIO state in the execution of its gpiochip ops, the driver caches things during probe time. However, since those ops can be called both during and immediately after the call to devm_gpiochip_add_data(), it is imperative that things are cached before that. That's not the case right now, so reorder the two steps to prevent any clobbering. In the concrete example which motivated this change, a bootloader was preconfiguring an important GPIO output to HIGH before booting the kernel. Linux would then inadvertently set that output to LOW while configuring a GPIO hog on a discrete GPIO line within the same 8-bit bank (because the cached value was 0=LOW). Fixes: ba9f507a1bea ("Input: adp5588-keys - export unused GPIO pins") Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260818-adp5588-gpio-cache-v1-1-650a2674fc0d@analog.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c3cd491be1ce57ecd0a3aa90b86aee661ca43533 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 0b8c8504593409954ed1a60db4e437d814e04023 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 128628d3788ae3b3a2eef1c0852239cf54c2210f 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 8a2c1bf209ba04cbd14153a771724bd5aa522fcd 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 bc5e79a5a5651588f3a93bef7815e4e86f78962c 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 d14c1bf80db74586380a9300c02fe119e59cceb2 Author: Florian Maillard Date: Mon Aug 24 08:57:55 2026 +0200 mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260 commit 9c182bc5d7817437a7d04ab96133f9191846d93d upstream. The Realtek RTS522A card reader in the Lenovo ThinkPad X260 (subsystem 17aa:504a) incorrectly reports inserted SD cards as write-protected. This causes the MMC core to expose the card as read-only: mmcblk0: mmc0:aaaa SN256 238 GiB (ro) and /sys/block/mmcblk0/ro reports 1. Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again. Limit the quirk to the affected Lenovo subsystem. Assisted-by: ChatGPT:GPT-5.6 Sol Signed-off-by: Florian Maillard Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 314966b490323bdcfd3162a1398b00e587e0ced4 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 f28709f4003c8c412d5e39cd15054fe8bc45aab3 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 bae1cf4f9902b2065bd78b759c7fe6312855f05e Author: Fan Wu Date: Thu Aug 6 13:02:33 2026 +0000 mmc: core: Cancel SDIO IRQ work before freeing host commit 6feadbecdae60a6324c967f3b1493741083793a3 upstream. A host controller that uses sdio_signal_irq() schedules host->sdio_irq_work from its interrupt handler. That work is only cancelled on the suspend path (mmc_sdio_suspend()), not on the remove/free path, so a worker armed just before the controller freed its IRQ can run after mmc_host_classdev_release() has freed the host and dereference it through container_of(). Cancel host->sdio_irq_work in mmc_free_host(), like the existing host->detect drain added by commit 1036f69e2513 ("mmc: core: Cancel delayed work before releasing host"). This issue was found by an in-house static analysis tool. Fixes: 682696605c70 ("mmc: sdio: Add API to manage SDIO IRQs from a workqueue") 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 f9da796fa238f8e4414ee8481e6c979759a3d563 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 a07bee32127d7c4cd3b1bb9a088e21d0c93634c9 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 a8d6d30f384e1c9eec36c3992226e4a99ede5a49 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 ea13a1ec9659cfd3e3a33bcfaf36dcc39773b3dd 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 b020b447338872440142fe8a57350a483da86b7a Author: Jarkko Sakkinen Date: Tue Sep 1 23:58:06 2026 +0300 KEYS: trusted: Fix tpm2_load_cmd() boundary check commit 114f00d738f15dd8c7318369edcdc53dd6d08763 upstream. tpm2_load_cmd() does boundary checks against the ASN.1 size i.e., payload->blob_len. Address this by passing the decoded blob size to tpm2_load_cmd(), and use it for the boundary checks. Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Reported-by: co+6a581c4284f721d4@bugs.sh Closes: https://bugs.sh/b/6a581c4284f721d4/ Reviewed-by: Stefano Garzarella Tested-by: Srish Srinivasan Link: https://lore.kernel.org/r/20260901205809.2028454-1-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 4d7e3a9500728c66bcfa1ffd827a8ce90776258f 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 0ff795163f37109a134b5a421558530f8d091544 Author: Yifei Gao Date: Tue Aug 4 21:34:56 2026 +0000 memstick: ms_block: destroy io_queue workqueue on removal commit 90af7fde083e1b22c349c3a8b1626728e44e474c upstream. msb_init_disk() creates the per-card ordered workqueue msb->io_queue with alloc_ordered_workqueue(). It is torn down with destroy_workqueue() only on the init error path; msb_remove() never destroys it. msb_stop() merely flushes the queue, and neither msb_data_clear() nor put_disk() free it. As a result every card insert/remove cycle leaks the workqueue and its kworker, exhausting kernel memory over repeated cycles. Destroy the workqueue in msb_remove() after the disk has been removed and the queue drained. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit aab7b23718f86eda17cdec3d5110180d43ce0e54 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 2daa618e7ff19eefcbda281bc4c5998c4140f9cf 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 06d2a101e89063cb0b9b459104db48bdfb0a797d 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 350fd3125ee26b5243935fd9e2b4d162ffba430a Author: Guanglei Zhu Date: Fri Sep 11 10:17:33 2026 +0800 net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value commit 31550d585589fde1ae95bf7f7a8188b2d2fdf1c7 upstream. mhi_mbim_rx() ignores the return value of skb_copy_bits() when it copies each datagram out of the NTB. The datagram offset and length come from the DPE, which is only checked to lie within the NTB itself, so a modem can point a datagram outside the received skb. The copy then fails and the freshly allocated skbn is passed to netif_rx() with its uninitialized contents still in place, leaking kernel heap memory into the network stack. Free the skb and account an error when the copy fails. Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") Cc: stable@vger.kernel.org Suggested-by: Loic Poulain Signed-off-by: Guanglei Zhu Signed-off-by: Greg Kroah-Hartman Verified in a QEMU guest with a fault injector pointing a DPE outside the received NTB: the copy fails, and the unpatched driver hands the uninitialized skbn to the network stack (observed as "unknown protocol" on bytes that were never written). With this check the failed datagram is dropped and counted as an rx error. Changes in v2: factor the free-and-count sequence out into mhi_mbim_rx_drop(), shared with the unknown-protocol path, as suggested by Loic Poulain. Link: https://patch.msgid.link/20260911021734.1396599-2-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit e4b2c7b50d4f4aa1ddfff731b136d65f65b2b526 Author: Guanglei Zhu Date: Fri Sep 11 10:17:32 2026 +0800 net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain commit 5d063822ac5184939c1ed377a339a01d8ae814e8 upstream. The NDP traversal in mhi_mbim_rx() only stops when wNextNdpIndex is zero. Nothing requires the offsets to advance, so a modem that points an NDP at itself, or at an earlier NDP, keeps the loop spinning forever on one CPU. Break out when the next NDP offset is not larger than the current one. Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") Cc: stable@vger.kernel.org Suggested-by: Loic Poulain Signed-off-by: Guanglei Zhu Signed-off-by: Greg Kroah-Hartman Verified in a QEMU guest with a fault injector feeding the driver's receive callback an NTB whose single NDP points at itself: the unpatched driver spins in mhi_mbim_rx() with one CPU pinned at 100% and the thread never returns. With this check the loop terminates within one iteration. Changes in v2: move the non-increasing check to the wNextNdpIndex retrieval site, as suggested by Loic Poulain, instead of tracking the previous offset in a separate variable. Link: https://patch.msgid.link/20260911021734.1396599-1-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit 0e52886c4324c9897c2c62f92be3dc8316cee67e Author: Mark Amirkan Date: Sun Sep 13 17:14:09 2026 -0700 net: lan743x: fix RX checksum use-after-free commit a9ce4053dc945c5372dedba5017ee675b30dc0c5 upstream. lan743x_rx_process_buffer() adds each non-first receive buffer to the head skb's frag_list. On the last descriptor, lan743x_rx_trim_skb() linearizes the head and frees the fragment skb metadata. The checksum-success path then writes ip_summed through the local skb pointer, which still points to the final fragment. This causes a use-after-free write when a packet spans more than one receive buffer. Set ip_summed on the surviving head skb instead. Multi-buffer receive can occur after a live MTU increase because existing ring entries keep their old buffer size until they are replenished. A KUnit test invoking lan743x_rx_process_buffer() with a two-buffer packet produced a one-byte KASAN use-after-free write before this change. The same test passed after the change. The driver object also builds with W=1. This was not tested on physical LAN743x hardware. Fixes: cd6910501cfd ("net: lan743x: Add support for Rx IP & TCP checksum offload") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Chenguang Zhao Link: https://patch.msgid.link/20260913-b4-send-lan743x-uaf-v1-1-73d563d08ba9@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 675919e08ce266b8cac11fd9af29170e762a480f 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 967612574c542dec71f820a6eb16dea80dd187a1 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 9728d5b917a6b3c51d558829e7e864fa8fab2890 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 4a6b430843487b72b960fd91a9ac2426b6dbc8a3 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 9f407d52c0d881430d689836d3e7d32aa36f98b5 Author: Chengfeng Ye Date: Sat Aug 22 01:43:50 2026 +0800 Bluetooth: hci_sync: Serialize local codec list cleanup commit 9a10987a2f160a44a638c9a35994ca6e3089696e upstream. hci_dev_close_sync() clears hdev->local_codecs after releasing hdev->lock. Codec list additions and both traversals in sco_sock_getsockopt() use that lock, but the close path does not. A close and BT_CODEC query can therefore interleave as follows: hci_dev_close_sync() sco_sock_getsockopt() hci_dev_lock() fetch codec entry hci_codec_list_clear() kfree(entry) read entry->id The reader then accesses an entry which the close path has freed. KASAN reported: BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0 Read of size 1 at addr ffff8881001c3450 Call Trace: sco_sock_getsockopt+0xfa0/0xfe0 do_sock_getsockopt+0x537/0x7b0 __sys_getsockopt+0xf2/0x170 Allocated by task 92: hci_codec_list_add.isra.0+0x2c/0x440 hci_read_codec_capabilities+0x224/0x590 hci_read_supported_codecs+0x2c2/0x640 Freed by task 92: kfree+0x131/0x3c0 hci_codec_list_clear+0xd8/0x160 hci_dev_close_sync+0x92a/0xfa0 Take hdev->lock around the clear operation at its existing point in the close path. This makes the clear wait for active readers and prevents a new traversal until the list is empty without changing teardown ordering. Fixes: b938790e7054 ("Bluetooth: hci_codec: Fix leaking content of local_codecs") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 9c04b9a4d08b95dee901d24b7607c4cbd65fa0a8 Author: Laxman Acharya Padhya Date: Mon Aug 24 21:42:36 2026 +0545 Bluetooth: hci_codec: validate vendor codec count length commit d0795cfd6f655f4de84868a4f4bb41a03f037b3d upstream. The Read Local Supported Codecs parsers consume the variable-sized standard codec array before parsing the vendor codec count. Although the initial reply-size check includes a vendor count byte in the fixed layout, it does not guarantee that the byte remains after the standard codec array. If a controller reply ends immediately after that array, calculating the vendor codec array size reads vnd_codecs->num beyond the skb data. Use skb_pull_data() to validate and consume each codec header before using its count in both command variants. Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details") Fixes: 9ae664028a9e ("Bluetooth: Add support for Read Local Supported Codecs V2") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Signed-off-by: Laxman Acharya Padhya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 7474d503df906bc27694de892542731ae14f228a Author: Aamir Ahmed Date: Mon Sep 7 00:37:43 2026 +0100 Bluetooth: eir: validate service data length before reading UUID commit e8241766794cf551d787fa3a77c0d54bbea6f6aa upstream. eir_get_service_data() reads a 16-bit UUID from the service data using get_unaligned_le16() without first checking that the data is long enough to hold a UUID16 (2 bytes). If a malformed EIR entry has a service data field with only 1 byte of payload (field_len=2), eir_get_data() returns dlen=1. The subsequent get_unaligned_le16() then reads 1 byte past the field boundary. Additionally, if the corrupted UUID happens to match, the length calculation "dlen - 2" underflows to SIZE_MAX since dlen is size_t. Current callers either pass NULL for the length parameter or bounds-check the returned length, but future callers may not. Add a check that dlen >= sizeof(u16) and skip fields that are too short to contain a valid UUID16. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Signed-off-by: Aamir Ahmed Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 4d84e1e63b015887f4e350ba8d482576b5e2a080 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 6d5ff2f315a9f98203c2133c9eb246aa87c0947d 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 5bc5cf65517f202def6fe6ca8bab831940b065a6 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 7256d71847b5d4089ff0b3cffdcc2905c371d7f8 Author: Koichiro Den Date: Fri Sep 11 16:30:58 2026 +0900 arm64: dts: renesas: r8a779f0: Set UFS lane count commit 8dc2615d5702059b2b71fca6f93c0d7d10ae54cb upstream. Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link"), the following error is observed on R-Car S4: ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1] ufshcd-renesas e6860000.ufs: link startup failed -67 ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67 ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67 R-Car S4 has one UFS lane per direction, as described in section 152.1 of its hardware manual. Without lanes-per-direction, the UFS platform driver defaults to two lanes. Previously, the core used PA_CONNECTEDRXDATALANES and PA_CONNECTEDTXDATALANES to configure the link without checking them against lanes-per-direction, so the missing property did not prevent initialization. Explicitly set lanes-per-direction to 1, now that the validation is in place. Fixes: 5235d551779d ("arm64: dts: renesas: r8a779f0: Add UFS node") Cc: stable@vger.kernel.org # 7.2+ Signed-off-by: Koichiro Den Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260911073058.253000-1-den@valinux.co.jp Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 6646418d1032cac25110526161f60d255ed08397 Author: Bradley Morgan Date: Sun Aug 9 21:36:15 2026 +0000 arm64: hibernate: pass HVC_SET_VECTORS args to the resume hvc commit 955d86e5f3b95b731991fdb84966c50b16314629 upstream. swsusp_arch_suspend_exit() reinstalls the restored kernel's hyp stub vectors with an hvc, but never passes the arguments. x0 is not set to HVC_SET_VECTORS and x1 is not set to the vector address, so the stub dispatch falls through and returns without writing vbar_el2. EL2 is left pointing at the trans_pgd copy of the vectors, a page that swsusp_free() releases right after resume. Set the arguments up the same way __hyp_set_vectors() does. Without this fix, Vladimir was able to trigger a hang when resuming from hibernation with CONFIG_PAGE_POISONING=y and page_poison=on. Fixes: 788bfdd97434 ("arm64: trans_pgd: hibernate: Add trans_pgd_copy_el2_vectors") Cc: stable@vger.kernel.org Signed-off-by: Bradley Morgan Reviewed-by: Vladimir Murzin Tested-by: Vladimir Murzin Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 0a75d7681c16555e78960857a34c05856756b2d7 Author: Thomas Huth Date: Wed Sep 9 17:57:07 2026 +0200 kselftest/arm64: Fix size of thread_data values for pthread_join() commit 3d1ba5cbfb622025690c218d8f20da92a9ecb383 upstream. pthread_join() stores the thread's return value (a "void *", i.e. 8 bytes on 64 bit computers) into the address that is passed as second parameter. However, the entries of thread_data are only normal "int"s, i.e. only 4 bytes. The additional 4 bytes of the return value clobber whatever is adjacent on the stack, i.e. other members of the thread_data array (which will be re-written in the next iteration of the for-loop, so that nobody noticed this problem), or another other local variable on the stack for the last iteration. Use "intptr_t" to declare the thread_data array entries with the correct size. Fixes: 29f080881601c ("kselftest/arm64: check GCR_EL1 after context switch") Cc: stable@vger.kernel.org Signed-off-by: Thomas Huth Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 4a8243fd2e21980fa3fd10c0610e9155057cebd3 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 05eab8dced6bf4d3009a6eeee16ddac99047dc83 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 ce8a379598bd4058081416abea4279fd05a95374 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 01e29d0d78a8f66f221625720a04939eef5ec1f6 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 b86e1e5a4bbcbbccde8b7a3d3486604b581f6628 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 344c72a0bc2703a6de4918ed935850e07dae3af2 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 4719424bb7cb9f20b73986bcb72dd528f0e5c6eb 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 8edc3669e3e22f0123a1114c3a03df9abc4cd465 Author: Yuho Choi Date: Thu Sep 10 23:11:21 2026 -0400 ALSA: virtio: reset device before deleting virtqueues commit 6c05d00af307560e6a9f1631d6270d3df5aa2272 upstream. virtsnd_remove() and virtsnd_freeze() delete the virtqueues before resetting the device. del_vqs() frees the vring backing, but does not provide a generic device quiesce operation. In particular, modern virtio-pci keeps enabled queues active until the device is reset. Reset the device before deleting the virtqueues so it can no longer access the vring memory when that memory is released. This also covers probe failures after DRIVER_OK, which unwind through virtsnd_remove(). Fixes: de3a9980d8c3 ("ALSA: virtio: add virtio sound driver") Fixes: 575483e90a32 ("ALSA: virtio: introduce device suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260911031121.1542502-1-oss.patchbox@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b65f871d9de4894438d863f4599bf483e68fe54e 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 7f397f7f7869bc6ec285d08dc810b4e87e57dc23 Author: Roberts Kursitis Date: Sun Sep 6 17:30:40 2026 +0300 Input: xpad - add support for Azeron devices commit cba76c0f47af1a389d718c5bb69e75cbd67bba98 upstream. Azeron controllers (Cyro, Cyborg, Classic/Compact, Cyro Lefty, Cyborg II and Keyzen) present a standard Xbox 360 controller interface, so they work with the existing xpad driver once their USB IDs are added. The 0x16d0 vendor ID is a shared block, but this is safe because xpad only binds interfaces that match the Xbox 360 signature. Tested with an Azeron Keyzen. Signed-off-by: Roberts Kursitis Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906143040.162418-1-roberts.kursitis@azeron.eu Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ddee9a667d3125a114a7cb70a792430b894c6c7c 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 de97cc9d33d10164d1733b0f77fc97a8562e5d0c Author: Andrea Righi Date: Sat May 9 20:07:28 2026 +0200 sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity [ Upstream commit bf6aa722198d3c06e4236e8c5a480f30a64e1513 ] When SD_ASYM_CPUCAPACITY load balancing considers pulling a misfit task, capacity_of(dst_cpu) can overstate available compute if the SMT sibling is busy: the core does not deliver its full nominal capacity. If SMT is active and dst_cpu is not on a fully idle core, skip this destination so we do not migrate a misfit expecting a capacity upgrade we cannot actually provide. Reported-by: Felix Abecassis Signed-off-by: Andrea Righi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://patch.msgid.link/20260509180955.1840064-5-arighi@nvidia.com Signed-off-by: Sasha Levin commit 5c45feb54fc4138c60f2af307d95749ffdbe58ec Author: Ricardo Neri Date: Thu Apr 6 13:31:37 2023 -0700 sched/fair: Move is_core_idle() out of CONFIG_NUMA [ Upstream commit 8b36d07f1d63de102d464f44a89704bc62d00811 ] asym_packing needs this function to determine whether an SMT core is a suitable destination for load balancing. Signed-off-by: Ricardo Neri Signed-off-by: Peter Zijlstra (Intel) Tested-by: Zhang Rui Link: https://lore.kernel.org/r/20230406203148.19182-2-ricardo.neri-calderon@linux.intel.com Signed-off-by: Sasha Levin commit c96cc6b46fdce89a8feb270a35bbe5086c142534 Author: Tomer Tayar Date: Mon Sep 21 13:26:39 2026 -0400 accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release() [ Upstream commit 2e8e9a895c4589f124a37fc84d123b5114406e94 ] The memory manager IDR is currently destroyed when user releases the file descriptor. However, at this point the user context might be still held, and memory buffers might be still in use. Later on, calls to release those buffers will fail due to not finding their handles in the IDR, leading to a memory leak. To avoid this leak, split the IDR destruction from the memory manager fini, and postpone it to hpriv_release() when there is no user context and no buffers are used. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay [ Backport to 6.1.y: this tree keeps Habanalabs under drivers/misc rather than drivers/accel; the source change is otherwise unchanged. ] Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit dfd46b5584a5881b131008767950e1ab82713c8c 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 88f6b1509a5eef6a8c78f3707ef268a5d0b4edc0 Author: James Clark Date: Tue Sep 15 11:58:17 2026 +0700 net: macb: fix ordering around PTP timestamp read [ Upstream commit 9ca4ba24259183ce15665be86b2956cd896c4687 ] PTP_SYS_OFFSET_EXTENDED returns system timestamps that do not correctly bracket the PHC register read on MACB/GEM. On a Raspberry Pi 5, the returned interval can be as short as 37 ns, while an ordered register read takes approximately 1 us. This biases the midpoint used by phc2sys, causing CLOCK_REALTIME to run approximately 0.5 us ahead when synchronized to the PHC. gem_tsu_get_time() reads the nanoseconds register using the driver's relaxed MMIO accessor. On weakly ordered systems, the subsequent system timestamp can be taken before the register read completes. The internal smp_rmb() in the pre-timestamp path also does not guarantee ordering against the subsequent MMIO read. Add rmb() before and after the bracketed nanoseconds read in both the normal and seconds rollover paths so the system timestamps bracket the PHC read. Adding the post-read barrier increases the minimum interval on the same Raspberry Pi 5 to approximately 1 us. Fixes: e51bb5c2784c ("net: macb: ptp: Switch to gettimex64() interface") Tested-by: Nicolai Buchwitz # Raspberry Pi CM5, min bracket 37 ns -> 981 ns Reviewed-by: Nicolai Buchwitz Reviewed-by: Théo Lebrun Assisted-by: LLM Signed-off-by: James Clark Link: https://patch.msgid.link/20260915045823.76100-1-jjc@jclark.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d72d87926ca33c6766dc73ace46859d7220a45bb 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 3b12d3967e96f1b7b977d9fc352ae29a1b299a82 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 662724469014454f6052bdf766a35d7aa7a572d8 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 c5d4be4209243f3e8a09b75915c243402e713143 Author: HyeongJun An Date: Tue Sep 15 18:25:15 2026 +0900 ASoC: hdmi-codec: Report a change when the channel status moves [ Upstream commit c17ae8c26eac16ad244daef44044d714f68a2ddc ] The put() callback of "IEC958 Playback Default" stores all 24 channel status bytes and then returns 0. The core notifies userspace only on a positive return, so a write that changes what the get() callback hands back is never announced, and a mixer holding the control open keeps showing the old value. Compare the stored bytes and return 1 when they move, the way snd_hda_spdif_default_put() does. The same shape is in img-spdif-out and uniperif_player. No board with this codec was to hand. The change is a comparison of driver state with no hardware behaviour in it, and mixer-test counts the missing notification as event_missing. Fixes: 7a8e1d44211e ("ASoC: hdmi-codec: Add iec958 controls") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260915092515.2638542-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db470b70c84aa526f6ddea94d1390c9cead98561 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 3776bf56e06980e8a12c8c0565d9e6ac44965f03 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 a933d7024359e2e566b07903d1294b84f90482ae 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 4d8f7b1f586375df8bce23a0909566ad5e852259 Author: Amit Machhiwal Date: Tue Sep 15 22:04:15 2026 +0530 KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid() [ Upstream commit 51938dfa8a51a4f85328413fca9b6e21f9d2d088 ] kvmhv_emulate_tlbie_all_lpid() iterates the nested-guest IDR and drops mmu_lock before calling kvmhv_emulate_tlbie_lpid(), but does not hold a reference on the kvm_nested_guest pointer obtained from the IDR. A concurrent vCPU issuing a single-LPID tlbie (is=2, ric=2) can race through kvmhv_flush_nested() -> kvmhv_remove_nested() -> idr_remove / --refcnt -> kvmhv_release_nested() -> kfree(gp) in that window, leaving the iterating vCPU with a dangling pointer. The subsequent mutex_lock(&gp->tlb_lock) and accesses to gp->shadow_pgtable, gp->shadow_lpid and gp->l1_host all touch freed memory. The free path is fully L1-controlled. Fix this by incrementing gp->refcnt inside the loop before dropping mmu_lock, mirroring what kvmhv_get_nested() does, and releasing the reference with kvmhv_put_nested() after the per-guest work completes. This is the same get/put discipline already used at every other call site that drops mmu_lock while holding a nested-guest pointer. Fixes: e3b6b4661527 ("KVM: PPC: Book3S HV: Implement H_TLB_INVALIDATE hcall") 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 88d640efd655b10f9fa4e381caf777da1f17c2a6 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 9896af99bb68339125e68bb3efcfe181da6914c7 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 e6cd1bba7d113c15c00ac63671213a096fe4d686 Author: Eric Dumazet Date: Sat Sep 12 23:30:48 2026 +0000 pppoatm: ensure a writable skb header and linear data [ Upstream commit ecc7253683a3c55caa868ce0ee530fcb0044bd3c ] In pppoatm_send(), LLC encapsulation checks whether there is sufficient headroom for the 4-byte LLC header, but does not ensure that the skb header is writable. Normal transmit packets passing through ppp_start_xmit() have their header unshared via skb_cow_head(). However, packets can also reach pppoatm_send() via PPP channel bridging (PPPIOCBRIDGECHAN) without going through ppp_start_xmit(). Use skb_cow_head() to ensure both sufficient headroom and a writable header before pushing the LLC header. While at it: - Call pskb_may_pull(skb, 1) before inspecting skb->data[0] to prevent out-of-bounds reads on zero-length or non-linear frames (e.g. from bridging). - Defer SC_COMP_PROT protocol compression until after pppoatm_may_send() succeeds. This eliminates the temporary skb allocation on admission failure and completely removes the fragile "undo" heuristic at the nospace label, avoiding any risk of reading uninitialized headroom or performing an unbalanced skb_push(). Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912233048.3977192-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4aafb47301a799d3e01230d6568c4e93524e1523 Author: Juan Perdomo Date: Sat Sep 12 23:09:45 2026 -0400 Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup [ Upstream commit 801fb950cae7048eb7d83b18857d1ca37b8cd5a4 ] rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts. Reported-by: syzbot+0cece8fa7d83523f47a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0cece8fa7d83523f47a3 Fixes: b7ce436a5d79 ("Bluetooth: switch to lock_sock in RFCOMM") Signed-off-by: Juan Perdomo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c09dfd6da91083748f1b06df9f5cbabd13cab2aa 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 d920c07aa6d89ec11afdb6976aafaee9563a5234 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 67b83c15bed9eeeb8d1a6dbf88a5f79525970173 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 7d94602e77a4525611afebb23149145ac242afd7 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 b9661fd2423fc25e91e0517ecc0b6156ad83e3a8 Author: Nikolay Aleksandrov Date: Fri Sep 11 13:50:21 2026 +0300 net: bridge: mst: move switchdev call outside rcu [ Upstream commit 18a6fe05fb6e18de29fa90d388bb34044114b3d8 ] This is a follow-up of one of sashiko's pre-existing bug reports. br_mst_set_state() calls switchdev_port_attr_set() for nonzero MSTIs while holding rcu_read_lock() which invokes the blocking switchdev notifier chain and may sleep. Nonzero MSTI changes come from netlink with rtnl held. Move the switchdev call before entering the rcu section and assert that rtnl is held. The call cannot be deferred because netlink needs its error and extack. Also DSA reads the old bridge MST state during the callback and checks it. A deferred callback will be late and will see the updated state. Fixes: 3a7c1661ae13 ("net: bridge: mst: fix vlan use-after-free") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260911105021.1385934-1-razor@blackwall.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d2e4e57c5baa92f9f6032f0e860e785a4b3d76a9 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 731db6110b3148331ed8d5d11a564bfd520721d9 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 06083cea4a3b95f5ebc85312f97d7086e6c9e782 Author: Dong Chenchen Date: Thu Sep 10 22:00:42 2026 +0800 ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup [ Upstream commit 2998147b59c9df0a51477c7a6b3d1f0ba3127dd4 ] When the forward output route cannot be used in icmp_route_lookup(), it enters the "reverse path" and calls ip_route_input() on fl4_dec.daddr, the original packet's source address. ip_route_input() only returns an error for truly invalid packets. For unreachable addresses it will succeed and return an input route whose dst.output is set to ip_rt_bug(). The existing check only rejects RTN_LOCAL routes, so the RTN_UNREACHABLE route types can still be returned and later used for output, syzkaller triggering a WARN_ON_ONCE() in ip_rt_bug() as bellow: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1273 at ip_rt_bug+0x14/0x20 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: ip_push_pending_frames+0xfa/0x100 __icmp_send+0x905/0xf10 ip_options_compile+0xc0/0xd0 ip_rcv_finish_core+0x321/0xae0 ip_rcv+0x1de/0x260 __netif_receive_skb_one_core+0x11a/0x130 netif_receive_skb+0x7b/0x260 tun_get_user+0x11bf/0x1c10 ------------[ cut here ]------------ Reject input route that is RTN_UNREACHABLE to fix it. The net warning is only printed for RTN_LOCAL, as RTN_UNREACHABLE is not the result of a race condition. Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Suggested-by: Ido Schimmel Reviewed-by: Jiayuan Chen Reviewed-by: Ido Schimmel Signed-off-by: Dong Chenchen Link: https://patch.msgid.link/20260910140042.1880242-1-dongchenchen2@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e4d7c52f15f572608374947c6c802052e1a2fc82 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 bb0f70d30c4f6b181e067c4e1b09a8ef0a56f4ad Author: Dmitry Baryshkov Date: Thu Sep 3 15:19:10 2026 +0300 drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL [ Upstream commit 2028280686f4fa78e2f1f6dede4b6c1fd782b9e3 ] DSI 6G v2.9 hosts (SM8650, SM8750, Kaanapali, etc.) reparent the byte and pixel RCGs to the DSI PHY PLL at runtime from dsi_link_clk_set_rate_6g_v2_9(), after the PHY has been enabled. However dsi_calc_clk_rate_6g() runs earlier, in order to compute the bit clock request for the PHY. At that point the byte RCG still has its reset parent (XO), so clk_round_rate() returns a bogus rate, which then ends up in the PHY bit clock request and the PLL gets programmed to a wrong frequency, breaking the panel. Move the rounding to dsi_link_clk_set_rate_6g(), which is called after the RCGs have been reparented to the PLL. Storing the rounded rate at this point still makes later link_clk_set_rate() calls no-ops in the CCF. Derive the byte interface clock rate from the rounded byte clock rate, otherwise it would keep requesting the idealized rate and retrigger the PLL on every transfer. Reported-by: Abel Vesa Reported-by: Krzysztof Kozlowski Fixes: 6cd33b6f4155 ("drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value") Assisted-by: LLM Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Tested-by: Konrad Dybcio # SM6115P J606F Tested-by: Abel Vesa Reviewed-by: Abel Vesa Patchwork: https://patchwork.freedesktop.org/patch/750496/ Link: https://lore.kernel.org/r/20260903-fix-eliza-dsi-v1-1-3474a6c9f2e0@oss.qualcomm.com Signed-off-by: Sasha Levin commit ec2c31828c602582ff00624c6c3532e1cdd6e580 Author: Dmitry Baryshkov Date: Wed Jan 18 15:00:27 2023 +0200 drm/msm/dsi: correct byte intf clock rate for 14nm DSI PHY [ Upstream commit 1d5e01dfa3410bc94476e3050485852d6bba3fe0 ] According to the vendor kernel, byte intf clock rate should be a half of the byte clock only when DSI PHY version is above 2.0 (in other words, 10nm PHYs and later) and only if PHY is used in D-PHY mode. Currently MSM DSI code handles only the second part of the clause (C-PHY vs D-PHY), skipping DSI PHY version check, which causes issues on some of 14nm DSI PHY platforms (e.g. qcm2290). Move divisor selection to DSI PHY code, pass selected divisor through shared timings and set byte intf clock rate accordingly. Cc: Loic Poulain Signed-off-by: Dmitry Baryshkov Tested-by: Konrad Dybcio # SM6115P J606F Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/519006/ Link: https://lore.kernel.org/r/20230118130027.2345719-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Stable-dep-of: 2028280686f4 ("drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL") Signed-off-by: Sasha Levin commit 212cb0bf0f7da0e9189d33514a9749a2409e4368 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 3c6ca6d9342f4a0be7c1413180e11023d13b5cde 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 f0a4b603d90d695147ba8dcfa257417417eb5142 Author: Thomas Zimmermann Date: Tue Feb 21 16:57:43 2023 +0100 drm/ast: Rework definition of I/O read and write helpers [ Upstream commit faf67f640fa6c036d19727e294a2915e3fe5bf7c ] Ast defines a number of I/O helpers for accessing hardware. Only 4 of the many generated functions are actually used. Replace the respective generator macros with those 4 functions. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230221155745.27484-3-tzimmermann@suse.de Stable-dep-of: 073a30d75f30 ("drm/vc4: Use managed KMS polling to fix UAF on unbind") Signed-off-by: Sasha Levin commit 9522e5881c4bb3a70796d85e1063d3397de998e9 Author: Thomas Zimmermann Date: Tue Feb 21 16:57:42 2023 +0100 drm/ast: Remove little-endianism from I/O helpers [ Upstream commit a38410860628909712ea6a2becd42bab56c70e9a ] Replace one call to ast_io_write16() with two calls to ast_io_write8() in ast_set_index_reg(). The combined 16-bit-wide write of an index register and the corresponding data register only works on little- endian systems. Write both registers independent from each other. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230221155745.27484-2-tzimmermann@suse.de Stable-dep-of: 073a30d75f30 ("drm/vc4: Use managed KMS polling to fix UAF on unbind") Signed-off-by: Sasha Levin commit 85082caa5449f0266b07e812dda2977b30713116 Author: Thomas Zimmermann Date: Thu Feb 9 16:41:02 2023 +0100 drm/atomic-helper: Add atomic_enable plane-helper callback [ Upstream commit 169b9182f192e8725c8de5d7d77f00f6ae6c7fd4 ] Add atomic_enable to struct drm_plane_helper_funcs. It enables a plane independently from updating the plane's content. As such, it is the inverse of the atomic_disable plane helper. Useful for hardware where plane enable state is independent from plane content. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-2-tzimmermann@suse.de Stable-dep-of: 073a30d75f30 ("drm/vc4: Use managed KMS polling to fix UAF on unbind") Signed-off-by: Sasha Levin commit f9526054c2b2cace5916b7225603d008834ec011 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 61e665fb48e9eee44ec6d610514af383b1802cc1 Author: Xiang Mei Date: Mon Sep 14 00:43:24 2026 -0700 ALSA: 6fire: fix OOB write from device-reported iso length [ Upstream commit 1589afe2d099d3e817873bc474676968d7080410 ] usb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as (actual_length - 4) / (in_n_analog << 2) * (out_n_analog << 2) + 4, where actual_length is the unsigned length the device reported for the matching IN packet. A packet completed with status 0 and actual_length < 4 wraps the subtraction to 0x7fffffec; a zero-length isochronous packet is legal on the bus, and the preceding loop rejects only non-zero status. The sum reaches memset() on out_urb->buffer, a 4832-byte object from kcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB). Even without the wrap the result is out of bounds: at 88.2/96 kHz the 4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight packets span 5024 bytes of that buffer. usb_submit_urb() rejects an over-long descriptor only after the memset() and the usb6fire_pcm_playback() copy of user PCM data have run. Guard the subtraction as the sibling usb6fire_pcm_capture() already does, and limit the frame count to what fits in rt->out_packet_size, the OUT endpoint's wMaxPacketSize. This bounds total_length by the buffer size while keeping each packet length aligned to a whole output frame. BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200) __asan_memset (mm/kasan/shadow.c:84) usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741) vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 10: __kmalloc_cache_noprof (mm/slub.c:5563) usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595) usb6fire_chip_probe (sound/usb/6fire/chip.c:133) usb_probe_interface (drivers/usb/core/driver.c:399) The buggy address belongs to the object at ffff88802a3d0000 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 0 bytes inside of 4832-byte region [ffff88802a3d0000, ffff88802a3d12e0) Kernel panic - not syncing: Fatal exception in interrupt Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Reported-by: co+855929c2df672879@bugs.sh Closes: https://lore.kernel.org/all/gisnub8aWGLbyZLcDCSc7zWsHonMWGcyRgt5%40bugs.sh/ Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260914074324.3590843-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3ef9093d83ffecb8e5f6c9d5769a52d39df74f7a Author: Takashi Iwai Date: Thu Sep 3 18:04:39 2026 +0200 ALSA: usb: 6fire: Avoid embedded URBs [ Upstream commit 9fe49dbc023e82dfaee7b245997d820d01742a9a ] The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward; each embedded struct urb is changed to a pointer, and its callers are updated accordingly. The resource for those structs are released in the common destructor functions (usb6fire_comm_free(), etc), which are called at both the init error path and the disconnect. No functional changes, only compile-tested. Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260903160458.1938392-4-tiwai@suse.de Stable-dep-of: 1589afe2d099 ("ALSA: 6fire: fix OOB write from device-reported iso length") Signed-off-by: Sasha Levin commit bfe0e79520ea9d38741c12e39aed9ca3109f173b Author: Takashi Iwai Date: Mon Aug 11 10:22:29 2025 +0200 ALSA: 6fire: Clean ups with guard() [ Upstream commit 6ff0d95774f0c728f96b8f78367318e95e09ee64 ] Simple code cleanups with the guard() for spinlock and mutex. No functional changes. Link: https://patch.msgid.link/20250811082231.31498-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: 1589afe2d099 ("ALSA: 6fire: fix OOB write from device-reported iso length") Signed-off-by: Sasha Levin commit 53c4bfdcf8f6da7d3e60cd30152cce9838542735 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 8c869d5cf5affb20994bdbb60e7d46d65c91b55f 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 3b824930259d54f5047ce6b5c97bd20db2fc2b98 Author: Takashi Iwai Date: Thu Sep 10 17:52:23 2026 +0200 ALSA: bcd2000: Fix race between rawmidi and disconnect [ Upstream commit 221253723dc58bb901c3f27a7659823e63fc598c ] Although we tried to fix the potential UAF issues at USB disconnect on bcd2000 driver, there is still an overlooked case -- namely, when a rawmidi trigger callback has been already running at USB disconnect handling, the in-flight function (e.g. bcd2000_midi_send()) could still access the URB, because the previous URB NULL-check & clearance was considered only for the URB complete callbacks, but not about the parallel rawmidi operations. For addressing the race, this patch introduced a new spinlock that covers each rawmidi operation as well as the rawmidi handling in the complete callback. The URB is cleared with the lock, so it guarantees that the pending rawmidi task already finished or a NULL check is effective. Fixes: 459d3a64766f ("ALSA: bcd2000: clear the URB pointers on disconnect") Link: https://patch.msgid.link/20260910155227.996210-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b82aec780a773903db0400648a3ae11f45262b13 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 88c450e23b8fd4f1dcd329562f5e81ef05f3d941 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 8abd61120b29d4b10b1334d283e2b9303e02bb27 Author: Shouping Wang Date: Thu Sep 10 19:46:01 2026 +0800 perf/arm-cmn: Fix wp_dev_sel2 setting for multi-DTM configurations [ Upstream commit 49daa3d668b69a5454b5aba0078848a479f79f1c ] When MXP_MULTIPLE_DTM_EN is TRUE, each DTM will monitor at most two device ports. In this case, {wp_dev_sel2, wp_dev_sel} will only use values 2'b00 and 2'b01 per DTM. Previously the setting allowed values beyond the supported range per DTM, which could cause each DTM to select invalid ports when MXP_MULTIPLE_DTM_EN is TRUE. Fix this by only setting CMN_DTM_WPn_CONFIG_WP_DEV_SEL2 when !multi_dtm. Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features") Signed-off-by: Shouping Wang Reviewed-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 61c6688be282277c6e91ab286a7acd0ae8681ac6 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 eb2030137dba3b59cbb5057a33af70488d6bc231 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 262dcd809723723ed8a4e05437ec7e9c21a8f17e 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 3cd652dfcd822af26ba75d6d2d245ea7f73b499e Author: Leon Romanovsky Date: Thu Sep 10 09:35:13 2026 -0400 RDMA/efa: Keep EQ resources alive while IRQ is registered [ Upstream commit e22a3627b7151754f07f90ea3d1ab6e85f5d93f4 ] The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ. Fixes: 2a152512a155 ("RDMA/efa: CQ notifications") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-2-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0a8a105978e5ace0d885964317c5aed8ab4c0a0c Author: Leon Romanovsky Date: Thu Sep 10 09:35:13 2026 -0400 RDMA/efa: Keep admin queues alive while IRQ is registered [ Upstream commit e08aca85c02ff290f785f07acae758f0daf5f49e ] The management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses. Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-1-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1dd22297cef75385201371d49061a90dcbab33f2 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 8ecbace7ce09661eedc4e37e39652a6c52e01726 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 0fed7eacbb908356a5c02767299593a9a453505b Author: Karl Mehltretter Date: Sun Sep 6 19:10:09 2026 +0200 scsi: qla2xxx: Fix the ql2xfc2target parameter description [ Upstream commit 779f202a92ef10a426efc07d0f4267918cb07ca3 ] The module parameter is ql2xfc2target, but its MODULE_PARM_DESC() names qla2xfc2target, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 877b03795fcf ("scsi: qla2xxx: Add option to disable FC2 Target support") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260906171009.2560-1-kmehltretter@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit df711e9fa20d7e996711c7f43a11a71805bef78d Author: Johannes Berg Date: Tue Sep 8 14:28:21 2026 +0200 wifi: mac80211: set up the TX info early to fix failure paths [ Upstream commit 50d3d79dc0743b616afb00d01a626c76758721f7 ] The previous commit 2c51457d930f ("wifi: mac80211: free ack status frame on TX header build failure") cleaned up the leak, but still left the code a bit messy and the failed SKB didn't get reported to userspace. Fix this up by initialising skb->cb[] earlier, which allows using ieee80211_free_txskb() and therefore reports it for the failure in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize() failure path with it. Assisted-by: LLM Fixes: c3e7724b6bc2 ("mac80211: use ieee80211_free_txskb to fix possible skb leaks") Link: https://patch.msgid.link/20260908122838.201719-22-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e0972e3692858abd1d1c0ab483c7d91575436d03 Author: Johannes Berg Date: Mon Aug 28 15:09:24 2023 +0200 wifi: mac80211: rework ack_frame_id handling a bit [ Upstream commit f498f6ab7adb461a68e13ea6d4443cb3636f2d93 ] Take one more free bit to indicate it's IDR vs. internal usage, to be able to carve out some bits here for other internal usage, other than IDR handling with a full ACK SKB, that is. Reviewed-by: Benjamin Berg Reviewed-by: Ilan Peer Signed-off-by: Johannes Berg Stable-dep-of: 50d3d79dc074 ("wifi: mac80211: set up the TX info early to fix failure paths") Signed-off-by: Sasha Levin commit f0afcec2129c166e61821d6ae097061155f01b12 Author: Johannes Berg Date: Tue Sep 8 14:28:20 2026 +0200 wifi: mac80211: mesh: release the channel if start fails [ Upstream commit ae97fff6495a8764bc0ef281cfe5444f701e527f ] ieee80211_join_mesh() acquires a channel context and then calls ieee80211_start_mesh(), which can fail. In that case, the chanctx isn't released then interface removal will attempt to unassign it after it's removed from the driver, hitting: wlan0: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.c:366 at drv_unassign_vif_chanctx ieee80211_assign_link_chanctx __ieee80211_link_release_channel ieee80211_link_release_channel ieee80211_teardown_sdata unregister_netdevice_many_notify _cfg80211_unregister_wdev ieee80211_remove_interfaces ieee80211_unregister_hw mac80211_hwsim_del_radio hwsim_exit_net Correctly release the channel on start failures. Assisted-by: LLM Reported-by: syzbot+63a84ea9c0f57d6133fa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=63a84ea9c0f57d6133fa Fixes: 2b5e19677592 ("mac80211: cache mesh beacon") Link: https://patch.msgid.link/20260908122838.201719-21-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit db19d5414227d86cee77a000607a6710d7f36853 Author: Johannes Berg Date: Tue Sep 8 14:28:18 2026 +0200 wifi: mac80211: add HE 6 GHz capability in the scan elems len [ Upstream commit cd54bf333f5631d3630bab0a832e9ae648f73515 ] The HE 6 GHz Band Capability element is in the probe request for every band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements can fail, triggering the WARN_ON in __ieee80211_start_scan(). Assisted-by: LLM Fixes: 2ad2274c58ee ("mac80211: Add HE 6GHz capabilities element to probe request") Reported-by: syzbot+f961b9f94edbc266f1f8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f961b9f94edbc266f1f8 Link: https://patch.msgid.link/20260908122838.201719-19-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4a4d4b38ab5442ab0fad0b470587272836b83de5 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 abba7e1cd4273b016cd33cd961ce77497e874187 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 32272ff3a039801f3de4ca77529f035cdcd1e8c4 Author: Johannes Berg Date: Tue Sep 8 14:28:15 2026 +0200 wifi: mac80211: don't allow link changes when iface is down [ Upstream commit 370872d30349d81dec519e15ea2949fd63511cf7 ] ieee80211_set_active_links() only checks that the interface is running in the inner __ieee80211_set_active_links(), after drv_can_activate_links() was already called, so using active_links on an interface that's down triggers the check-sdata-in-driver warning. Add the missing check in the debugfs file. Assisted-by: LLM Fixes: 3d9011029227 ("wifi: mac80211: implement link switching") Reported-by: syzbot+582469b3a9ef5f13606b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=582469b3a9ef5f13606b Link: https://patch.msgid.link/20260908122838.201719-16-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6bae6ef511a29ef12ab969adeea691067d4d5d74 Author: Johannes Berg Date: Tue Sep 8 14:28:14 2026 +0200 wifi: mac80211: require a peer station for TDLS setup confirm [ Upstream commit 038e1d126304fd25d507fd4e671232df57bd1799 ] It's nonsense for the setup confirm to go to station that doesn't even exist, and it hits a warning when building the frame: WARN_ON_ONCE(!sta || !ap_sta) Only accept WLAN_TDLS_SETUP_CONFIRM when the station is already there as a TDLS station. Need to copy the call to ieee80211_tdls_prep_mgmt_packet() since the existing WLAN_TDLS_DISCOVERY_REQUEST already falls through to it. Assisted-by: LLM Fixes: 6f7eaa47e1de ("mac80211: add TDLS QoS param IE on setup-confirm") Reported-by: syzbot+e55106f8389651870be0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e55106f8389651870be0 Link: https://patch.msgid.link/20260908122838.201719-15-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d5de88ed7a4f4e7c8473fcc6307a6ada007ddd47 Author: Mukesh Sisodiya Date: Fri Jun 16 09:53:51 2023 +0300 wifi: mac80211: handle TDLS negotiation with MLO [ Upstream commit 78a7ea370d5f0eb6f3e774e7f6afece1c3a6860f ] Userspace can now select the link to use for TDLS management frames (indicating e.g. which BSSID should be used), use the link_id received from cfg80211 to build the frames. Signed-off-by: Mukesh Sisodiya Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20230616094948.ce1fc230b505.Ie773c5679805001f5a52680d68d9ce0232c57648@changeid [Benjamin fixed some locking] Co-developed-by: Benjamin Berg Signed-off-by: Benjamin Berg [fix sta mutex locking too] Signed-off-by: Johannes Berg Stable-dep-of: 038e1d126304 ("wifi: mac80211: require a peer station for TDLS setup confirm") Signed-off-by: Sasha Levin commit a5fcb2b18a7d88d90b1041c1b57ecc0a5a98bed1 Author: Mukesh Sisodiya Date: Fri Jun 16 09:53:50 2023 +0300 wifi: cfg80211: make TDLS management link-aware [ Upstream commit c6112046b1a9c130c455ab0bbe74c3f41138693c ] For multi-link operation(MLO) TDLS management frames need to be transmitted on a specific link. The TDLS setup request will add BSSID along with peer address and userspace will pass the link-id based on BSSID value to the driver(or mac80211). Signed-off-by: Mukesh Sisodiya Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20230616094948.cb3d87c22812.Ia3d15ac4a9a182145bf2d418bcb3ddf4539cd0a7@changeid Signed-off-by: Johannes Berg Stable-dep-of: 038e1d126304 ("wifi: mac80211: require a peer station for TDLS setup confirm") Signed-off-by: Sasha Levin commit 2bb87d1b3f2f35080f27d7d16c14e8329823e5f8 Author: Johannes Berg Date: Thu Jan 19 14:45:47 2023 +0100 wifi: cfg80211: trace: remove MAC_PR_{FMT,ARG} [ Upstream commit 3d9c361713f24f3f55b9622d18d32add1910e6ba ] With %pM, this really is no longer needed, and actually longer to spell out. Remove it. Signed-off-by: Johannes Berg Stable-dep-of: 038e1d126304 ("wifi: mac80211: require a peer station for TDLS setup confirm") Signed-off-by: Sasha Levin commit 304a874670a0b6ab5589a7f60b4af0251797b121 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 5ce9b2bc9e73213e316a8c72400256a76bf41814 Author: Johannes Berg Date: Fri Sep 4 17:01:35 2026 +0200 wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping [ Upstream commit 87840d4a3a21b1c19b867a80e16ba69dff284de2 ] The code checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit the WARN_ON(!local->started). Expand the mutex for this case and synchronise against it when the radio is stopped to avoid being able to hit the warning with hwsim. Drop the error print that would've complicated the error path, it only triggers for allocation failures (already noisy) and malformed frames anyway. Assisted-by: LLM Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx") Reported-by: syzbot+b4aa2b672b18f1d4dc5f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b4aa2b672b18f1d4dc5f Link: https://patch.msgid.link/20260904170140.5f69a10d606b.I4a7921d00643f69e439c7a3b221d104f66a3dcdc@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a22c02863439993095acd0c3db97fa53cd515f4f Author: Johannes Berg Date: Fri Sep 4 17:02:01 2026 +0200 wifi: mac80211: unlist vifs when their netdev is unregistered [ Upstream commit eee2efd82867b623982ac51925b5a1812a74c50d ] mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211_if_remove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the init_ns, but that can run into allocation failures. Then, mac80211 has an interface listed that doesn't exist, and will eventually hit BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()! ... _cfg80211_unregister_wdev+0x24/0x36a [cfg80211] cfg80211_unregister_wdev+0x15/0x1d [cfg80211] ieee80211_remove_interfaces+0x1ff/0x257 [mac80211] ieee80211_unregister_hw+0x73/0x1d1 [mac80211] mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim] Remove the interface from the list in ->ndo_uninit if it's still around to avoid this. Assisted-by: LLM Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.038ad73e6c04.I990abca78483e058746b6f42b4796717c3028164@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2ae0b7635f0aa13513c3d18752ad7c66e02e408a Author: Johannes Berg Date: Fri Sep 4 16:57:10 2026 +0200 wifi: mac80211: suppress chanctx warning for debugfs reset [ Upstream commit bf29d085e0eba92388518719d044f4702a8c6644 ] Before suspend all the channel contexts should removed, so the warning makes sense and should be there, but during reset the same code is called without first removing. Limit the check to the real suspend case. Assisted-by: LLM Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Reported-by: syzbot+56a1a45a9a2c04d425ff@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=56a1a45a9a2c04d425ff Link: https://patch.msgid.link/20260904165722.fe46395e310b.Ic4aaa95bd9d0ceb6a3cd7d84c425afee7d7d3dd7@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fb445ec7480da5d2b82bf681e3b4313603722729 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 3658093df69849daf4f813a8f087f358e13be203 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 cbb3310a5167e868a5e763e32b9a23b4d50669ee 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 c9780b601438137494b407eb4301bb3de2587ac9 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 57f7f1c6827be7d8f80feca48d2125fb91c6f6ed 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 fd86eca8526259d8d9a17fee952a78ad1c037ce0 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 4482d2c0c1512416b0cc48c0b7964484afb2f88a 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 d2e4973436c9d6675afea58b1c10bdb1555d8f1d 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 53728188186c8685215ff94ab138bb05fa657b07 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 c4fbcf1e614ef0755fcc751fdfca21b0bf4e0ef7 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 1b11e4b55b41d9e69a8e8d07622614202e2eaca9 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 400b89217058fac672134a0d4092c8493dadb8ad 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 89959ff00a978f3172726d3d5f861ee6f1aae26d 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 fcac5813f324cd07dfd36b4adf624fc70f7587d6 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 d177eca79e1106834bc423d3969a4a2e3987996a 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 30158808e921adb3bf4983e81584e6ad79d7bfbe 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 74c4ed55e61f1b65ddbebc5b635d136461a1c3da Author: Quanye Yang Date: Sun Aug 30 15:09:55 2026 +0800 RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted [ Upstream commit 2ae16aaa78b5edc6e6d0904c84fd9cdfb762bcda ] The client borrows shared CQ credits in the ADDR_RESOLVED handler via ib_cq_pool_get(), before the peer is connected. create_cm() can return -ERESTARTSYS from wait_event_interruptible_timeout() without destroying the CM ID. The init_conns() and stop-and-destroy paths then call destroy_con_cq_qp() while cq is still NULL (no PUT) and only afterwards rdma_destroy_id(). CMA serializes the handler against rdma_destroy_id() with handler_mutex, but that does not order the GET against destroy_con_cq_qp(). If ADDR_RESOLVED has already passed the DESTROYING check, it can take con_mutex, GET credits, and then lose the con to kfree. Device unregister later hits WARN_ON(cq->cqe_used) in ib_cq_pool_cleanup(). Set a per-connection flag under con_mutex before CQ/QP teardown so a racing ADDR_RESOLVED cannot borrow credits after teardown has begun. Reported-by: syzbot+d396918a29afb8543e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d396918a29afb8543e1c Fixes: 3b89e92c2a95 ("RDMA/rtrs: Use new shared CQ mechanism") Signed-off-by: Quanye Yang Link: https://patch.msgid.link/20260830-rdma-rtrs-clt-cq-pool-leak-v1-1-b169434fd3df@proton.me Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cc1f16da65965309f89a3b4573975d61f8b9e1e5 Author: Jacob Moroni Date: Tue Sep 1 16:00:14 2026 +0000 RDMA/irdma: Enforce local fence for IB_WR_REG_MR [ Upstream commit 3fb905f07ea45b31c8f67ba6e4668de46f527e65 ] Enforce local fence for IB_WR_REG_MR to avoid spurious FASTREG_VALID_MKEY async events during heavy invalidation and registration activity. Commit 69e8e429bca2 ("RDMA/irdma: Enforce local fence for LOCAL_INV WRs") was very similar, but was not sufficient to prevent all occurrences of these async events. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260901160014.2026285-1-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bad289e42f512646a988f278f536d21547df73f1 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 0e230917670c6e6fe3243abfa11299fcbe05b1f4 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 19ddd4af7fce9200e70882f622011e9dd130f427 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 be4b44c8b47c67a04c08b1a0aba18006b749ae6a Author: Krystian Kaniewski Date: Wed Aug 12 10:16:41 2026 +0200 RDMA/core: Reject unregistering netdevs in ib_get_eth_speed [ Upstream commit ef9fbe1b93f3b617b96e86d5cd76b3fa44514cb5 ] ib_device_get_netdev() intentionally returns a referenced net_device even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct net_device allocated, but does not guarantee that the device remains operational. ib_get_eth_speed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit have completed. Check for NETREG_REGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them. Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete. Fixes: d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev") Reported-by: syzbot+5fe14f2ff4ccbace9a26@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5fe14f2ff4ccbace9a26 Signed-off-by: Krystian Kaniewski Link: https://patch.msgid.link/20260812081708.32468-1-krystianmkaniewski@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a2d377476e256147dba1f89ec37e40b81bd2132a Author: Eric Dumazet Date: Tue Feb 13 06:32:36 2024 +0000 net: convert dev->reg_state to u8 [ Upstream commit 4d42b37def70327b2bb19f823d42289aed2cd7c7 ] Prepares things so that dev->reg_state reads can be lockless, by adding WRITE_ONCE() on write side. READ_ONCE()/WRITE_ONCE() do not support bitfields. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: ef9fbe1b93f3 ("RDMA/core: Reject unregistering netdevs in ib_get_eth_speed") Signed-off-by: Sasha Levin commit 8d2cad0b9d01421eb80bdb6c9113ea39c8babfd7 Author: Jiri Pirko Date: Wed Nov 2 17:02:02 2022 +0100 net: devlink: take RTNL in port_fill() function only if it is not held [ Upstream commit d41c9dbd12745cfc1cb2946cd99016d83c2c5364 ] Follow-up patch is going to introduce a netdevice notifier event processing which is called with RTNL mutex held. Processing of this will eventually lead to call to port_notity() and port_fill() which currently takes RTNL mutex internally. So as a temporary solution, propagate a bool indicating if the mutex is already held. This will go away in one of the follow-up patches. Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski Stable-dep-of: ef9fbe1b93f3 ("RDMA/core: Reject unregistering netdevs in ib_get_eth_speed") Signed-off-by: Sasha Levin commit ba2371c7d91ecc3ccc0f42117c4975ac0821072e Author: Jiri Pirko Date: Wed Nov 2 17:02:01 2022 +0100 net: devlink: move port_type_netdev_checks() call to __devlink_port_type_set() [ Upstream commit 45791e0d00c445936bb19535fe847083b1edd26d ] As __devlink_port_type_set() is going to be called directly from netdevice notifier event handle in one of the follow-up patches, move the port_type_netdev_checks() call there. Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski Stable-dep-of: ef9fbe1b93f3 ("RDMA/core: Reject unregistering netdevs in ib_get_eth_speed") Signed-off-by: Sasha Levin commit c8ec1113480aafb2a695d6a32156f2bc8ad37fc6 Author: Jiri Pirko Date: Wed Nov 2 17:02:00 2022 +0100 net: devlink: move port_type_warn_schedule() call to __devlink_port_type_set() [ Upstream commit 8573a04404ddacb2d966eef09bf38b2ad6dbe86f ] As __devlink_port_type_set() is going to be called directly from netdevice notifier event handle in one of the follow-up patches, move the port_type_warn_schedule() call there. Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski Stable-dep-of: ef9fbe1b93f3 ("RDMA/core: Reject unregistering netdevs in ib_get_eth_speed") Signed-off-by: Sasha Levin commit e39eed871cde636a2c45ec41b675a49f9eff603b Author: Jiri Pirko Date: Wed Nov 2 17:01:59 2022 +0100 net: devlink: convert devlink port type-specific pointers to union [ Upstream commit 3830c5719af66fac9849cf5fb04b03d4e4bb46ff ] Instead of storing type_dev as a void pointer, convert it to union and use it to store either struct net_device or struct ib_device pointer. Signed-off-by: Jiri Pirko Signed-off-by: Jakub Kicinski Stable-dep-of: ef9fbe1b93f3 ("RDMA/core: Reject unregistering netdevs in ib_get_eth_speed") Signed-off-by: Sasha Levin commit ddb43ac0926d4a931bc9b7744b93627f627457e5 Author: Michael Bommarito Date: Tue Jun 16 22:27:28 2026 -0400 RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds [ Upstream commit 1caceeb2d74bbe88223aea55eb8626b4c5f076fd ] rxe_get_mcg() publishes a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address with rxe_mcast_add(), which runs outside mcg_lock. A local userspace RDMA client reaches this path with ATTACH_MCAST on a UD QP; if rxe_mcast_add() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxe_mcg from __rxe_lookup_mcg(). Fix this by keeping the new mcg private until rxe_mcast_add() succeeds. Split the tree publication into __rxe_publish_mcg(), call rxe_mcast_add() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcg_tree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcg_lock finds the winner; this caller then drops its private object and balances its own rxe_mcast_add() with rxe_mcast_del() before returning the winner. Reproduced by forcing the rxe_mcast_add() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in __rxe_lookup_mcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean. Fixes: a926a903b7dc ("RDMA/rxe: Do not call dev_mc_add/del() under a spinlock") Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260617022728.2770116-1-michael.bommarito@gmail.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0f89e2ac0e945da2ce798f6a61aebf9d291c2e0a 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 7daaa684097377b66b98a832de307688a7f3bbc7 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 ad50d19f3d1ce052b3a146143581e930a1efb33e 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 638240fcee4e2c59bdbaea98e5b4f16eb48285c9 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 5119139c43a8a1ae48d732c142e0ee984ffaf613 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 9458a740586903bb313a368783bf4c3329833f38 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 2359264f377cdbdef2d95868cc8fb572949e48d3 Author: Maher Azzouzi Date: Mon Aug 17 14:37:52 2026 +0100 esp: downgrade zerocopy managed frags before mutating skb frags [ Upstream commit f89416eb3db151170a6f3c6dfc5239d26cdce4d2 ] On the out-of-place output path (esp->inplace == false) ESP rewrites the skb frag array: esp_output_head() appends a trailer frag and esp_output_tail() replaces the frags with a destination page, both referenced with get_page(). When the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS) the payload frags are owned by the ubuf and must not be referenced or unreferenced individually, but ESP mutates the frag array without ever downgrading the skb. This breaks the managed-frag invariant two ways: - esp_ssg_unref() walks the source scatterlist and drops a page reference for every frag, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages are still pinned, i.e. a use-after-free of the zerocopy pages; - esp_output_tail() installs its destination page as frag 0 with get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so skb_release_data() takes the skip_unref branch and never drops that reference, leaking the x->xfrag page at packet rate. Fix this the way every other frag-mutating site does (__ip_append_data(), __ip6_append_data(), tcp_sendmsg_locked()) and call skb_zcopy_downgrade_managed() before ESP touches the frag array: it takes a real reference on each existing frag and clears SKBFL_MANAGED_FRAG_REFS, so the per-frag unref in esp_ssg_unref() and the frag release in skb_release_data() are both balanced and no mixed-ownership frag array is left behind. Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure") Signed-off-by: Maher Azzouzi Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 6601d91a85761f33351c71e04ec0bbd294ca07ce Author: Eric Dumazet Date: Fri Aug 7 17:15:33 2026 +0000 xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() [ Upstream commit d2f5082f9e84653fa1a9e8aebaaff23e688f5e19 ] syzbot reported a suspicious RCU usage warning in ip6_pkt_drop(): WARNING: suspicious RCU usage in ip6_pkt_drop include/net/addrconf.h:389 suspicious rcu_dereference_check() usage! Call Trace: __in6_dev_get_safely include/net/addrconf.h:389 [inline] ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620 ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrm_trans_reinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where local_bh_disable() does not enter an RCU read-side critical section under CONFIG_PREEMPT_RCU. Because finish callbacks (such as ip6_rcv_finish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcu_read_lock() triggers RCU lockdep warnings. Furthermore, packets queued to the workqueue via xfrm_trans_queue_net() may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref). Additionally, on netdevice unregistration, dst_dev_put() replaces dst->dev with blackhole_netdev, so dst entries do not keep skb->dev alive while queued in the workqueue. Fix these issues by: 1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject(). Fixes: 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Steffen Klassert Cc: Liu Jian Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 42971ea17c7a8afc0bdd5ca40648bf4e5bb7b810 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 b28f93914193e059d8e7a522911937de74c679ac 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 7661ca6113d286b2e91679c39a60818936472e99 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 1f55c64910ff80b67a5842e4da13db9373953584 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 a4a32ddafeacebbd2a92eaa8a3fef95371075041 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 58421bd5f49a1335f08a3d7d23d342e2fb6713e5 Author: Sasha Levin Date: Sun Sep 20 11:16:26 2026 -0400 Revert "perf cs-etm: Flush thread stacks after decoder reset" This reverts commit 097df36140476ce86b23bfaa2fb9104a9c095752. Signed-off-by: Sasha Levin commit d347dd1dbdff7967f71709b19a298f9541375afe Author: Sasha Levin Date: Sun Sep 20 11:16:26 2026 -0400 Revert "perf cs-etm: Avoid truncating AUX buffer sizes to int" This reverts commit 9ccb4d7bd325012505d2d5d2456cad199417be57. Signed-off-by: Sasha Levin commit 839773c57659451e767389a328a92444fc77fb72 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 bdbc4cd52350d7dd23247212172fd142b4d02cba Author: Günther Noack Date: Thu Sep 17 17:00:05 2026 +0200 selftests/landlock: Add tests for whiteout object creation [ Upstream commit ee890889b30b22f9a21636061def7a04e4f89380 ] Add tests to check that whiteout object creation is guarded by LANDLOCK_ACCESS_FS_MAKE_REG, in the cases where these are created from userspace: * Conventional creation with mknod() * Linking or renaming an existing whiteout object * renameat2() with RENAME_WHITEOUT, which creates a new whiteout object in the source location * renameat2() with RENAME_EXCHANGE, with one of the renamed objects being a whiteout object Signed-off-by: Günther Noack Link: https://patch.msgid.link/20260813093157.1436894-4-gnoack@google.com [mic: Update commit message as requested] Signed-off-by: Mickaël Salaün [mic: Backport: adapt the tests to the older filesystem fixture and ruleset helper] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 690b9a8db9460d065785548e43fd6a02d247c1b7 Author: Guangguan Wang Date: Fri Sep 18 12:53:53 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: SMCD_CLC_MAX_V2_GID_ENTRIES does not exist in 6.1; SMC_MAX_ISM_DEVS is the same limit (8) under its pre-b40584d14570 name ] Signed-off-by: Junjie Cao Signed-off-by: Sasha Levin commit 238d9565b88a21d3f659c2c915bda8003f541e62 Author: Sasha Levin Date: Fri Sep 18 13:52:05 2026 -0400 Revert "alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally" This reverts commit a51363d8b28e3d05a2a63ea0c9167bc1494bf5af. Signed-off-by: Sasha Levin commit 535ffdcf50911d2c867da5477c66699754b70ef6 Author: Sasha Levin Date: Fri Sep 18 13:52:05 2026 -0400 Revert "alpha: don't leak hardware-fabricated FP exception bits to user space" This reverts commit 096eeed5c31bcfcc04fda3faeb87fafad3890ba8. Signed-off-by: Sasha Levin commit c7034fc81ad1e694553aa6a1b3dda9d1613aa76a Author: Mickaël Salaün Date: Thu Sep 17 17:00:04 2026 +0200 selftests/landlock: Add disconnected leafs and branch test suites [ Upstream commit 54f9baf537b0a091adad860ec92e3e18e0a0754c ] Test disconnected directories with two test suites (layout4_disconnected_leafs and layout5_disconnected_branch) and 43 variants to cover the main corner cases. These tests are complementary to the previous commit. Add test_renameat() and test_exchangeat() helpers. Test coverage for security/landlock is 92.1% of 1927 lines according to LLVM 20. Cc: Günther Noack Cc: Song Liu Cc: Tingmao Wang Link: https://lore.kernel.org/r/20251128172200.760753-5-mic@digikod.net Signed-off-by: Mickaël Salaün [mic: Backport: skip empty rules, use the older fixture teardown, and explicitly detach nested mounts] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 7325dd2326bd5720aef7a2a3195d56a1c95a82f0 Author: Tingmao Wang Date: Thu Sep 17 17:00:03 2026 +0200 selftests/landlock: Add tests for access through disconnected paths [ Upstream commit a18ee3f31fd714173a62515d049d77e76ab55649 ] This adds tests for the edge case discussed in [1], with specific ones for rename and link operations when the operands are through disconnected paths, as that go through a separate code path in Landlock. This has resulted in a warning, due to collect_domain_accesses() not expecting to reach a different root from path->mnt: # RUN layout1_bind.path_disconnected ... # OK layout1_bind.path_disconnected ok 96 layout1_bind.path_disconnected # RUN layout1_bind.path_disconnected_rename ... [..] ------------[ cut here ]------------ [..] WARNING: CPU: 3 PID: 385 at security/landlock/fs.c:1065 collect_domain_accesses [..] ... [..] RIP: 0010:collect_domain_accesses (security/landlock/fs.c:1065 (discriminator 2) security/landlock/fs.c:1031 (discriminator 2)) [..] current_check_refer_path (security/landlock/fs.c:1205) [..] ... [..] hook_path_rename (security/landlock/fs.c:1526) [..] security_path_rename (security/security.c:2026 (discriminator 1)) [..] do_renameat2 (fs/namei.c:5264) # OK layout1_bind.path_disconnected_rename ok 97 layout1_bind.path_disconnected_rename Move the const char definitions a bit above so that we can use the path for s4d1 in cleanup code. Cc: Günther Noack Cc: Song Liu Link: https://lore.kernel.org/r/027d5190-b37a-40a8-84e9-4ccbc352bcdf@maowtm.org [1] Signed-off-by: Tingmao Wang Link: https://lore.kernel.org/r/20251128172200.760753-4-mic@digikod.net Signed-off-by: Mickaël Salaün [mic: Backport: adapt the tests to the older fixture teardown] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 4f5cdc82a6c7e22cfd9a92d203cec13a52a3f363 Author: Mickaël Salaün Date: Thu Sep 17 17:00:02 2026 +0200 landlock: Fix handling of disconnected directories [ Upstream commit 49c9e09d961025b22e61ef9ad56aa1c21b6ce2f1 ] Disconnected files or directories can appear when they are visible and opened from a bind mount, but have been renamed or moved from the source of the bind mount in a way that makes them inaccessible from the mount point (i.e. out of scope). Previously, access rights tied to files or directories opened through a disconnected directory were collected by walking the related hierarchy down to the root of the filesystem, without taking into account the mount point because it couldn't be found. This could lead to inconsistent access results, potential access right widening, and hard-to-debug renames, especially since such paths cannot be printed. For a sandboxed task to create a disconnected directory, it needs to have write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to the underlying source of the bind mount, and read access to the related mount point. Because a sandboxed task cannot acquire more access rights than those defined by its Landlock domain, this could lead to inconsistent access rights due to missing permissions that should be inherited from the mount point hierarchy, while inheriting permissions from the filesystem hierarchy hidden by this mount point instead. Landlock now handles files and directories opened from disconnected directories by taking into account the filesystem hierarchy when the mount point is not found in the hierarchy walk, and also always taking into account the mount point from which these disconnected directories were opened. This ensures that a rename is not allowed if it would widen access rights [1]. The rationale is that, even if disconnected hierarchies might not be visible or accessible to a sandboxed task, relying on the collected access rights from them improves the guarantee that access rights will not be widened during a rename because of the access right comparison between the source and the destination (see LANDLOCK_ACCESS_FS_REFER). It may look like this would grant more access on disconnected files and directories, but the security policies are always enforced for all the evaluated hierarchies. This new behavior should be less surprising to users and safer from an access control perspective. Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and fix the related comment. Because opened files have their access rights stored in the related file security properties, there is no impact for disconnected or unlinked files. Cc: Christian Brauner Cc: Günther Noack Cc: Song Liu Reported-by: Tingmao Wang Closes: https://lore.kernel.org/r/027d5190-b37a-40a8-84e9-4ccbc352bcdf@maowtm.org Closes: https://lore.kernel.org/r/09b24128f86973a6022e6aa8338945fcfb9a33e4.1749925391.git.m@maowtm.org Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER") Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Link: https://lore.kernel.org/r/b0f46246-f2c5-42ca-93ce-0d629702a987@maowtm.org [1] Reviewed-by: Tingmao Wang Link: https://lore.kernel.org/r/20251128172200.760753-2-mic@digikod.net Signed-off-by: Mickaël Salaün [mic: Backport: adjust the filesystem walk and errata insertion context] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 5883ae880f51edc4b1484e787473b865b6159ead Author: Paolo Abeni Date: Sat Sep 19 22:12:56 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 Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit a370e56024df0b07e3120c45a9773ae123819fd6 Author: Paolo Abeni Date: Sat Sep 19 22:12:55 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 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. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit ccb8fda3e104fa41283f229661747e120c2feade Author: Paolo Abeni Date: Sat Sep 19 22:12:54 2026 +0200 mptcp: consolidate subflow cleanup commit c3349a22c2002947d29a98a77bfb36d97cfbfac1 upstream. Consolidate all the cleanup actions requiring the worker in a single helper and ensure the dummy data fin creation for fallback socket is performed only when the tcp rx queue is empty. There are no functional changes intended, but this will simplify the next patch, when the tcp rx queue spooling could be delayed at release_cb time. Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-1-4a47d90d7998@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 2b0f561f21b2 ("mptcp: avoid unneeded actions on subflow reset") [ Note: also remove struct mptcp_sock *msk from subflow_state_change: it is no longer used after this modification. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit fddc97944ea747e98fddc1b2f98bea1e446593b4 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 6117968fe2cdcde28ac3aa6ec814485320af4049 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 b69af40720cabd13da763575022a3d4430b02dfc 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 b3f9c3e60aa25453774f899d25b5e61dd0bec1d5 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 d643fd42ad96f19b5ce5cb11824fefa617191dbe 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 72ca5e0b8b7a62615758f8871c34d61616c2dc8b 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 6a5f5a5a32c78e67701f1d0f26bc87af68895604 Author: Kazuki Hanai Date: Wed Sep 16 21:26:02 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 7c940a1100cb0aa18a54dc48d736c0525c0f400c Author: Gary Guo Date: Tue Jul 7 13:26:44 2026 +0100 net: usb: pegasus: don't rely on id table pointer arithmetic [ Upstream commit ce8101c331956bbd3e20681331dfd22eb7c1c1ea ] The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. Instead of keeping a side table for additional information, use driver_info field of the usb_device_id. The dynamic ID parsing code needs to be updated for this; convert it to just write to the reserved entry for dynamic ID and remove the weird loop. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-5-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c708da7ff9ebcade5f3e60f5e8c4dca1aa67eab7 Author: Gary Guo Date: Tue Jul 7 13:26:43 2026 +0100 media: as102: do not rely on id table address comparison [ Upstream commit 91a8c8c718889fc8ccf5c38b750d790e9f36f92d ] The driver info should be retrieved using the driver_info field, not by address comparison. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-4-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f0c810f1b0cef15805b33bb4cc09c3e09663c124 Author: Gary Guo Date: Tue Jul 7 13:26:41 2026 +0100 usb: usbtmc: don't store usb_device_id [ Upstream commit fc045acec1a501c97f84ae184aadce9dae4ba9b2 ] usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. This stored ID is unused so remove it. Reviewed-by: Manuel Ebner Reviewed-by: Danilo Krummrich Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-2-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 664ef8ce390fa6575c3a3dc003f9ccdd7cca9932 Author: Gary Guo Date: Tue Jul 7 13:26:40 2026 +0100 wifi: ath9k_htc: don't store usb_device_id [ Upstream commit 14d2ac442d660e112efc0ce87ad10085013ed2b1 ] usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from usb_device, so just store driver_data. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-1-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ee4006c2175e8b50ff5d47a54bff52eb29bb1f0d Author: Gary Guo Date: Tue Jul 7 13:26:45 2026 +0100 usb: xusbatm: don't rely on id table pointer arithmetic [ Upstream commit eb6cd6d3d8abeac5d7e8251b898067184afdad8a ] The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. xusbatm initialize the USB device IDs dynamically so it can just use driver_info too. Even with conversion, xusbatm still cannot support dynamic IDs, so also set no_dynamic_id. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-6-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a911a970ed03e57887977f287e8748b1a8608175 Author: Sasha Levin Date: Wed Sep 16 12:33:05 2026 -0400 Revert "perf tests: Fix flakiness in BPF counters test on hybrid systems" This reverts commit 08c1316f983d3e1777f9087bb466dc5cf9a476f8. Signed-off-by: Sasha Levin commit 0dbec5e5b95ef57279433b285df7dd074085e7a0 Author: Sasha Levin Date: Wed Sep 16 12:31:48 2026 -0400 Revert "nvme: apple: Add Apple A11 support" This reverts commit 655b6743bd900df39354e8bb6f1f2f8671fca004. Signed-off-by: Sasha Levin commit a28f3215a14245fa6f5534338c8516d0b0297085 Author: Sasha Levin Date: Wed Sep 16 12:31:47 2026 -0400 Revert "nvme-apple: Drop the PRP null check chicken bit" This reverts commit 201edb5f22d4d126a48fb69850a2a7f190982e59. Signed-off-by: Sasha Levin commit 75b4ab1818f64c06fc8c8386ee5205c968a61d5d Author: Sasha Levin Date: Wed Sep 16 12:31:47 2026 -0400 Revert "nvme-apple: Prevent shared tags across queues on Apple A11" This reverts commit 91d3b243bffe5c94503c9a8ea478a080f79ec58e. Signed-off-by: Sasha Levin commit ed32d8bd79a75411429b9eec8359221e7b5e9e53 Author: Sasha Levin Date: Wed Sep 16 12:31:47 2026 -0400 Revert "nvme-apple: Reset q->sq_tail during queue init" This reverts commit 225b7af1dbd589c33faabe90b5bd85bd6a73b8b6. Signed-off-by: Sasha Levin commit 7e0a818ecc4d62e7fb668ea02de0bfe8ba0b7dff 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 aefbe02ac31a74680d1ec05e775336c23c574c19 Author: Sasha Levin Date: Wed Sep 16 12:29:38 2026 -0400 Revert "arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entries" This reverts commit 34c6835023896943696e4f2c192dc850240982cc. Signed-off-by: Sasha Levin commit 9db133cf1f6237884a45791498aab3315780b4c2 Author: Sasha Levin Date: Wed Sep 16 12:29:38 2026 -0400 Revert "arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entries" This reverts commit 7312115432d2ad14ccf92b2359d57bb039a239e3. Signed-off-by: Sasha Levin commit 1746df52f24498aa6a37d06dd3cb3e26267bb86d Author: Sasha Levin Date: Wed Sep 16 12:29:38 2026 -0400 Revert "arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entries" This reverts commit 6a8666fc1c629863022899046f8c46f3bb45a68e. Signed-off-by: Sasha Levin commit 61fc224cce5c7c15165a1a0a4352020381a5dc31 Author: Sasha Levin Date: Wed Sep 16 12:29:37 2026 -0400 Revert "arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entries" This reverts commit 98d41e690de05a6367300ab85bdeddff1af933a4. Signed-off-by: Sasha Levin commit 3162748782e3fb4fa6c76a6867a35c3720b9d7ff Author: Sasha Levin Date: Wed Sep 16 12:29:37 2026 -0400 Revert "arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entries" This reverts commit 2eec945bc94f35ae597e4ce49bc4f4b581ee82a0. Signed-off-by: Sasha Levin commit 359a005d6ba0a94add5e4717013d5df1235f0e11 Author: Sasha Levin Date: Wed Sep 16 12:29:37 2026 -0400 Revert "arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entries" This reverts commit d831304f2079e114fa74e585bf667a83fdbc25c8. Signed-off-by: Sasha Levin commit d165690f8a1861439a1509e0b164158894bf6abb Author: Suraj Jitindar Singh Date: Wed Sep 16 00:27:18 2026 +0000 bpftool: remove duplicate free_btf_vmlinux() definition v6.1.188 backported 660a19e46942 ("tools/bpf/bpftool: Reset vmlinux BTF after map commands") [ upstream commit 66d7e39e49b0 ] which re-adds free_btf_vmlinux(). However, the prerequisite cleanup 52df1a8aabad ("bpftool: remove function free_btf_vmlinux()") was never backported to 6.1.y, so the tree still carried the original free_btf_vmlinux() definition. The backport therefore produced two identical-signature static definitions in tools/bpf/bpftool/map.c and the build fails: map.c: error: redefinition of 'free_btf_vmlinux' Remove the stale pre-existing definition, keeping the one reintroduced by 660a19e46942 (which also resets btf_vmlinux = NULL). This matches the current mainline end state. Fixes: 660a19e46942 ("tools/bpf/bpftool: Reset vmlinux BTF after map commands") Signed-off-by: Suraj Jitindar Singh Signed-off-by: Sasha Levin commit 55c5f095d4df14271b238f826e1392fda7b6e60e Author: Bjoern Doebel Date: Fri Sep 4 10:42:36 2026 +0000 smb: client: avoid leaking refcount when cifs_sb_tlink() fails commit 23b26f4408ac3f35a482d2e5cf6fc865d4201b71 upstream. cifs_oplock_break() takes over the reference that cifs_queue_oplock_break() acquired when it queued the work, and drops it with _cifsFileInfo_put() once the break has been processed. Only in setups with "-o multiuser", cifs_sb_tlink() may fail, at which point cifs_oplock_break() returns without putting the file reference, mirroring the reference leak we already fixed in the companion patch to cifs_queue_oplock_break(). This would trigger a crash due to busy inodes on the next unmount: BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) Drop the reference on that path as well. Doing so before the out label mirrors the normal path, which also puts the reference before cifs_done_oplock_break(). Found by Sashiko code review. The failure path was not exercised at runtime. Fixes: e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 735a3a610136ae10f381d0909dff38e5b5c5f056 Author: Bjoern Doebel Date: Thu Sep 3 21:28:58 2026 +0000 smb: client: avoid leaking refcount in cifs_queue_oplock_break() commit 9f2e63f1b2d5fc5b5423424902c091123e220e7e upstream. cifs_queue_oplock_break() unconditionally takes a reference on the target file before queueing cifs_oplock_break(). Only that work item decreases the reference counter again. If another oplock break arrives while that work is still queued, queue_work() will return false and not queue this second work item. As a result, we will never reach the point to drop the file reference again and are leaking this reference. This can be triggered when interacting with a slow-responding server. As a result, later unmount operations for this file system will fail with BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) kernel BUG at fs/super.c:777! Fix this by only incrementing the reference count if the work has been queued successfully. Taking it after queue_work() is safe because all three callers hold tcon->open_file_lock across the call and _cifsFileInfo_put() decrements under that same lock, so a worker that starts the handler in the window cannot drop the reference before it has been taken. Fixes: b98749cac4a69 ("CIFS: keep FileInfo handle live during oplock break") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit f29c1ec0e7d8c887a91df3f93bb4617c0ac95c6a Author: Aohan Mei Date: Wed Sep 2 20:52:13 2026 +0800 smb: client: reject userspace cifs.idmap descriptions commit d9d7eeb0cea5b55b82888f443622fd8d4ee064f3 upstream. cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in "os:"/"gs:"/"oi:"/"gi:" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions"), which applied the same restriction to cifs.spnego. Fixes: 4d79dba0e007 ("cifs: Add idmap key and related data structures and functions (try #17 repost)") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Acked-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 9e4996721b9deb8fc9318cd67a9c72f7dc3e0b31 Author: Gang Yan Date: Tue Sep 8 16:07:12 2026 +0200 selftests: mptcp: fix an UAF in mptcp_connect.c commit 730444f094b12052916ebd7e14fe57bc3d47bf38 upstream. At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)', the 'peer' pointer (which points into 'addr') remains. Later, the main loop uses this peer pointer for reconnection attempts. If the memory has been freed and reused, the address data could be overwritten, resulting in an invalid remote address. This patch keeps the addrinfo list allocated for the whole process lifetime so "peer" remains valid across reconnects; the memory will be released at exit() time. Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-7-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b138e7dc719f0a3949de8bb6500b8cf1604eea06 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 ee00ad9cb2e1eb40c80eca70a6232edd98f2324a Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:07 2026 +0200 mptcp: subflow: no need to copy thmac during ulp_clone commit 29f641951be0d91036d77edf677807f1447dbe65 upstream. 'thmac' is not used after that point. Indeed, subflow_ulp_clone() is called when the request on the passive side is over, so when the truncated HMAC is no longer needed. Note that in case of SYN cookies, thmac will not be initialised. So better to remove it to avoid a warning from debug tools like KMSAN for reading uninitialised data. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN 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-2-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8065ced3ce2907d4b86a930e749249b6c8504d8e Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:10 2026 +0200 mptcp: options: handle MPC data + csum reqd + no csum commit ab36b1a80942c78ddb04d006ff38aa7ed3ec0e5e upstream. Before this modification, a remote peer could send an MP_CAPABLE with data, with the checksum flag set, but without adding the actual 2 bytes of checksum. As a result, uninitialised bytes could be used for the 'csum' field. That was not a critical issue, because this 'csum' field is only used to compare with the expected one, if previously negotiated in the 3WHS. Worst case, the checksum is likely wrong, a fallback is done without a reject if the negotiation was done earlier. That's OK. Yet, better to take the expected path with this case: only look at the checksum flag for MP_CAPABLEs not carrying a data-len. Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1] that the 3rd packet should have the checksum flag set. When an MPC + ACK contains data, the checksum flag is redundant with the checksum field. It is not clear what should be done for the 4th ACK, nor if the flag has to be set if the checksum field is set. Therefore, it seems fine to only look at the presence of the checksum field, not to break the interaction with stacks that were not setting both. Note that linked to this checksum flag on the 3rd ACK, with the current implementation, we can have a situation where the SYN packets have no checksum flag, but the 3rd ACK has one, and this is the one that will be taken into account. First, that's clearly not directly linked to this patch, but Clashiko forced us to look at that. At the end, that seems fine to act like that: yes that's not how the negotiation should work, but being flexible without introducing side effects is also fine: fixing this would mean increasing the complexity, and that's not worth it. Fixes: 208e8f66926c ("mptcp: receive checksum for MP_CAPABLE with data") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-23 [1] Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=1 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-5-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1f2d333ae2e1a73b7cc1c2a627587024cd147c01 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 af9a2bdaba0b4ceb0fc5e5122ef3fc6b7e5a366a 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 fc18d1d33e5d55043e131e5f8d7e7faf08c90783 Author: Joe Damato Date: Tue Sep 1 18:56:44 2026 -0700 bnxt_en: Only restore LRO if the device supports TPA commit 4e17b5007b6664559cdad2b2fe270526cf786b5b upstream. With a P5+ device with firmware that reports max_aggs_supported == 0, it is possible to make LRO settable by attaching and detaching an XDP program even though the device does not support TPA. Fix this by testing BNXT_SUPPORTS_TPA before restoring the feature bit. Fixes: f0aa6a37a3db ("eth: bnxt: always recalculate features after XDP clearing, fix null-deref") 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-2-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 975e0180488966bb709092a52408604bd4f4edd9 Author: Michael Bommarito Date: Tue Jun 16 22:18:58 2026 -0400 media: v4l2-ctrls: validate HEVC tile counts commit dc694a9929f7cb9c88ef91e45eb982b7bbe5a477 upstream. The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks. Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f781fbe631d6dd8991d2a5b7a41e0c7fee77fec0 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 6d192fc0d6faff25ecf6d52cbde4b939cb12c192 Author: Michael Bommarito Date: Tue Jun 16 22:19:02 2026 -0400 media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity commit 06236b094c899c22c12ac5097935eb6719293de8 upstream. prepare_tile_info_buffer() writes one entry per tile into the tile_sizes DMA buffer, sized for a grid equal to the PPS uAPI array capacity. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers so the loops stay inside the buffer. Fixes: cb5dd5a0fa51 ("media: hantro: Introduce G2/HEVC decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4a0a3732c7e31aca443dadcf20dc2996995d17b6 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 8f51e3c657218d318158ffdd0ff48c505adb41c7 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 6e67d9bdac810edacef78cbaeedd34445aa8ceb7 Author: Fan Wu Date: Wed Aug 19 03:33:17 2026 +0000 hwmon: (gpio-fan) Fix use-after-free in alarm work commit a2471ed17b0e6ff7bfb6b2ea8e6e5b04c309d293 upstream. fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool. Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260819033317.446191-1-fanwu01@zju.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit dec85bee9f2b2d7ea17c79cfd96f0131ee06e529 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 e17b85eb8cee90a1200fa5e7806db7ffa08a0608 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 fd6fff2417d40c379982c2b345fe3ec14d95e00a 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 5aa211eced140f52e1efd35218f6dc6933beff3d 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 1a8f15911352bb3cf4663aa02049c49c7f30e524 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 125890702ef4417cd0ffac2e448c0cd4fbf0ac45 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 16d8e0b560d50cd1a9e6d77a9a154a94c4d6021e 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 ab664e279eb2a68e55895dd115a9488807280f07 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 a1d6c6c31dfc55b22b305e42dbf6ff77765118d1 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 b0514ca1ee6f2b708d6c602ea946acdfc6a90e24 Author: Chengfeng Ye Date: Mon Aug 24 01:05:38 2026 +0800 netfilter: nf_log: unregister loggers before per-net teardown commit 2c018cc4842c33f0c732962e2ab58635e8ae5823 upstream. nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration. Fixes: 5b023fc8d8e0 ("netfilter: enable per netns support for nf_loggers") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 017dbbf0d6c319a487f68e22f56d91fc787d5525 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 38db09804b2616aa1e2fcdf97f0c3ae8b9dbdd34 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 4931ddded69ff476b1684845df2b9b7c281ebcdc 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 f63fc22e7dd522892e2559d5ab36d2b925826a43 Author: Sebastian Andrzej Siewior Date: Fri Sep 11 12:21:52 2026 +0200 ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters() commit 815e07c8fe885a87751c2496a30ae0dcd4118210 upstream. rb_wake_up_waiters() is a irq_work callback which is initialized with init_irq_work(). As such it will be invoked in thread context on PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an option due its usage of wake_up_all(). Since this callback may run in thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with disabling interrupts and may not assume that they are disabled. Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de Fixes: 68282dd930ea3 ("ring-buffer: Fix resetting of shortest_full") Reviewed-by: Vincent Donnefort Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3726824aa1418594a7458721f8b8cafd5393a300 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 5aacc19ba2b1faf84c4a2f2cf9a1784e03d1ff38 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 b14987a0f73777644099f47f01aba3b0f9dc6c27 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 ca52482508b3ac9febe74ca4f732647d394727b8 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 3a9552d18fc8174bab015bc941ede19452b184b3 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 2e27144ba4b98bb3eb14aaccd4b088e2e69844e3 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 89c978d67ad01ce28223944cc58e95feea177b35 Author: Donggeun Yoo Date: Mon Sep 7 15:03:23 2026 +0900 tracing: Keep the entry count when the histogram stats allocation fails commit 06f5634ec5584954177f9a22e36b3bfb398a971b upstream. print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: n_entries = tracing_map_sort_entries(map, ...); if (n_entries < 0) return n_entries; ... if (!stats) { n_entries = -ENOMEM; goto out; } ... out: tracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map->max_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end. Reading the hist file of a trigger with a .percent value, with that allocation forced to fail: BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0 Read of size 8 at addr ffffc90000045000 by task init/1 tracing_map_destroy_sort_entries+0xa0/0xb0 hist_show+0x6f7/0x1df0 seq_read_iter+0x2b8/0x1190 vfs_read+0x176/0xa40 The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50 A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284. Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path. The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with "tracing: hist: let values keep the percent and graph modifiers", so it should be applied first. Cc: stable@vger.kernel.org Fixes: abaa5258ce5e ("tracing: Add .percent suffix option to histogram values") Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/ Signed-off-by: Donggeun Yoo Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1448dd755c171b782eb1c5c2308ed5619df801ed Author: Donggeun Yoo Date: Mon Sep 7 14:21:13 2026 +0900 tracing: Let histogram values keep the percent and graph modifiers commit 3d617bfd79330ae3acf94862c18bb3ccf5f5a0f9 upstream. The .percent and .graph modifiers exist only for histogram values, but a value carrying either of them has been rejected since v6.3. The example in Documentation/trace/histogram.rst, # echo 'hist:keys=prev_comm:vals=hitcount.percent:nohitcount' > \ events/sched/sched_switch/trigger returns -EINVAL. parse_field() sets the two flags only when the field is neither a key nor a variable, that is, only on a value: } else if (strncmp(modifier, "percent", 7) == 0) { if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY)) goto error; *flags |= HIST_FIELD_FL_PERCENT; __create_val_field() then rejects a value for carrying them, so no field can reach hist_trigger_print_val(), where both are implemented. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") added the check after a value with .buckets oopsed in hist_field_name(). That happens because .buckets and .log2 make create_hist_field() build a nested field in operands[0] which hist_field_name() then walks into. The percent and graph flags do not create an operand and are not read by hist_field_name(); they are only used when printing a value. Stop rejecting the two flags on a value. The check for variables is left alone, where they are unreachable anyway because parse_field() rejects a variable carrying them first. With the two flags removed, the trigger above installs and prints as documented: { prev_comm: rcu_preempt } hitcount (%): 0.00 { prev_comm: init } hitcount (%): 99.98 Totals: Hits: 237896 Cc: stable@vger.kernel.org Fixes: e0213434fe3e ("tracing: Do not let histogram values have some modifiers") Link: https://patch.msgid.link/20260907052113.430818-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a2652fcf96b63e9da04951e4e58e6a0672df695d Author: Donggeun Yoo Date: Mon Sep 7 12:49:48 2026 +0900 tracing: Free histogram the field rejected for a bad modifier commit 230234d12ce42ab04132a32c3a848f07a5d27a71 upstream. Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) { if (hist_field->flags & (...)) goto err; } else { if (hist_field->flags & (...)) goto err; } hist_data->fields[val_idx] = hist_field; Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to create_hist_data(), which calls destroy_hist_data() -> destroy_hist_fields(), and that reaches a field only by walking fields[]. A field that never got there is unreachable. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") set ret to -EINVAL and fell through to the store, which left the field owned by fields[] and freed along with the rest of hist_data. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it. With CONFIG_DEBUG_KMEMLEAK, 200 writes of # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \ events/sched/sched_switch/trigger each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at create_hist_field(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since create_hist_field() puts the plain field in operands[0] of the log2 field, and both are reported. Use destroy_hist_field() rather than __destroy_hist_field() so that operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF, which is what an operand owned by hist_data->var_refs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag. Cc: stable@vger.kernel.org Fixes: e30fbc618e97 ("tracing/histograms: Allow variables to have some modifiers") Link: https://patch.msgid.link/20260907034948.240387-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a1f1d64a0a9791c842c4646253daf6ac0313eac7 Author: Donggeun Yoo Date: Sun Sep 6 21:40:25 2026 +0900 tracing: Free histogram var refs regardless of how often they are referenced commit 4bddcb346a6cf4615ca77f69a589623b877ca267 upstream. Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") then made repeated references share one object and added a count of them. Only the increment side exists, since those expressions still return early and never drop a reference, so __destroy_hist_field() sees how many references were created rather than how many are left. It frees when the decremented count is 0 or 1, so two references work and three or more leak. Sharing kept one array entry per object, and create_var_ref() searches and appends within a single trigger, so nothing outside it holds the object. Removing a trigger whose variables are still referenced is already refused by check_var_refs() with -EBUSY. Drop the count and free unconditionally. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com Fixes: 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 352f84a381e7b4651b30366e93cb858f3fa9c91a 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 338d6859cd1580617807290f6d7e92b1662d4695 Author: Thomas Gleixner Date: Mon Aug 12 16:19:48 2024 +0200 tick/broadcast: Plug clockevents replacement race commit 113a9796effe3376d2ec5aabcca1fef4fef4cd62 upstream. 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA CPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; tick_install_broadcast_device(dev) clockevents_exchange_device(cur, dev) shutdown(cur); detach(cur); cur->handler = noop; tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state. The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations. The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation. That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock. Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it. Fixes: f8381cba04ba ("[PATCH] tick-management: broadcast functionality") Reported-by: 朱恺乾 Signed-off-by: Thomas Gleixner Signed-off-by: Thomas Gleixner Reviewed-by: Bradley Morgan Tested-by: 刘术高 Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87cymdsu0r.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit 4574f26ca9beb3652b8faf8d8a97cc5c9ca09292 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 e4c5cc9688c3e69d07d888853388549ae26c0521 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 5cc48633fb76196b596a449ba1f4f642ad6125ce 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 b2c7903866e27fd1eab37ccfd00240310e4ab4be 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 850ec83eb71d9dac08b8c306adffba0a148a36b2 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 869fb83c072e884b80d93eab498e6040ffb010ba Author: Tristan Madani Date: Fri Sep 4 20:58:25 2026 +0000 ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf commit 861111a14740e12c36d363e9830f8daa734279c9 upstream. The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260904205826.4071119-1-tristmd@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 29a5cf4213107cb71eada5c4801ac55b74b6d8d6 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 05b687ee04f816658f4a9cf586f4d2f129157943 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 a58531181363219fa5de2b53d5d7274dcdfca98b 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 864155c164654110f68a17a63bd0339754790d67 Author: Eric Dumazet Date: Fri Aug 21 15:33:38 2026 +0200 ipv4: start using dst_dev_rcu() [ Upstream commit 6ad8de3cefdb6ffa6708b21c567df0dbf82c43a8 ] Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF. Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(), ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu(). Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-9-edumazet@google.com Signed-off-by: Jakub Kicinski [ minor modifications to fix conflict, added rcu_read_lock and unlock to ip_defrag function ] Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit 4a4193f13ff32d814b35070f95e3dbf0e2501a10 Author: Eric Dumazet Date: Fri Aug 21 15:33:37 2026 +0200 net: dst: introduce dst->dev_rcu [ Upstream commit caedcc5b6df1b2e2b5f39079e3369c1d4d5c5f50 ] Followup of commit 88fe14253e18 ("net: dst: add four helpers to annotate data-races around dst->dev"). We want to gradually add explicit RCU protection to dst->dev, including lockdep support. Add an union to alias dst->dev_rcu and dst->dev. Add dst_dev_net_rcu() helper. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Miguel Gazquez Signed-off-by: Sasha Levin commit 4594e39388a34917ef4d678af5d8e8fcaece036d Author: Eric Dumazet Date: Fri Aug 21 15:33:36 2026 +0200 ipv4: adopt dst_dev, skb_dst_dev and skb_dst_dev_net[_rcu] [ Upstream commit a74fc62eec155ca5a6da8ff3856f3dc87fe24558 ] Use the new helpers as a first step to deal with potential dst->dev races. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250630121934.3399505-8-edumazet@google.com Signed-off-by: Jakub Kicinski [ minor modifications to fix conflict ] Signed-off-by: Miguel Gazquez Signed-off-by: Sasha Levin commit 218d5b182592b389b6badb1ec37a0a46d0d99cba Author: Eric Dumazet Date: Fri Aug 21 15:33:35 2026 +0200 net: dst: add four helpers to annotate data-races around dst->dev [ Upstream commit 88fe14253e181878c2ddb51a298ae8c468a63010 ] dst->dev is read locklessly in many contexts, and written in dst_dev_put(). Fixing all the races is going to need many changes. We probably will have to add full RCU protection. Add three helpers to ease this painful process. static inline struct net_device *dst_dev(const struct dst_entry *dst) { return READ_ONCE(dst->dev); } static inline struct net_device *skb_dst_dev(const struct sk_buff *skb) { return dst_dev(skb_dst(skb)); } static inline struct net *skb_dst_dev_net(const struct sk_buff *skb) { return dev_net(skb_dst_dev(skb)); } static inline struct net *skb_dst_dev_net_rcu(const struct sk_buff *skb) { return dev_net_rcu(skb_dst_dev(skb)); } Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250630121934.3399505-7-edumazet@google.com Signed-off-by: Jakub Kicinski [ minor modifications to fix conflict ] Signed-off-by: Miguel Gazquez Signed-off-by: Sasha Levin commit 0127f1c119bde40578f4d25f5d17333b4e75de8c Author: Namjae Jeon Date: Tue Sep 15 21:48:06 2026 +0900 ksmbd: prevent out-of-bounds reads in share config responses [ Upstream commit f25e93768fcc5d8287e50b1ec52a42e4c276df34 ] Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length. Fixes: a677ebd8ca2f ("ksmbd: validate payload size in ipc response") Reported-by: Kanishka De Silva Reported-by: Farhad Alemi Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f806f54ae3de780b8f4139baefc95b81c599cf9f 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 74d5138959203f57782f548844f46a7774f6a714 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 01ba5b36898d6258f584269537cc49e7b05cf7c6 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 9251573e7cf7d797ae4a30b2a236af8242237a61 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 76e4aab61020d68a022acf5e3c7c6ed76c7c730b Author: Eelco Chaudron Date: Tue Sep 8 16:15:17 2026 +0200 openvswitch: fix wrong flag value in get_ipv6_ext_hdrs() [ Upstream commit e184a4a6f423550a25adce867036cdb1ff471745 ] The ESP and AH cases in get_ipv6_ext_hdrs() used IPPROTO_FRAGMENT instead of OFPIEH12_FRAG when checking for out-of-order extension headers, causing the fragment header to not be recognised as a valid predecessor. The original code used IPPROTO_FRAGMENT (44) as a bitmask constant where OFPIEH12_FRAG (1 << 4 = 16) was intended. IPPROTO_FRAGMENT encodes bits 2, 3 and 5 (OFPIEH12_AUTH | OFPIEH12_DEST | OFPIEH12_ROUTER), but not bit 4 (OFPIEH12_FRAG). This caused incorrect OFPIEH12_UNSEQ verdicts in both the ESP and AH arms: the ESP arm failed to whitelist OFPIEH12_FRAG, while the AH arm accidentally whitelisted OFPIEH12_AUTH. With the fix, a packet with two AH headers now also gets OFPIEH12_UNSEQ in addition to OFPIEH12_UNREP, matching the ESP arm which already sets UNSEQ on a repeat, which is the intended behavior. Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension header support") Reported-by: Paolo Abeni Reviewed-by: Aaron Conole Reviewed-by: Ilya Maximets Signed-off-by: Eelco Chaudron Link: https://patch.msgid.link/1b1582eb07550d71f3cbe210e5cb31eeb8d0ad86.1788876917.git.echaudro@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ee74a4b42e3a2f9635ba376be9e58311322eebe4 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 148b8cf7051336f2a8cc9908a97433f186432598 Author: Ratheesh Kannoth Date: Fri Sep 4 14:21:13 2026 +0530 octeontx2-af: fix PF/CGX debugfs PCI bus lookup [ Upstream commit 4f4b743c2d2bbc336cb164d9d3d2ed6956ad8437 ] rvu_dbg_rvu_pf_cgx_map_display() locates each RVU PF PCI device via pci_get_domain_bus_and_slot() when printing the PF-to-CGX map. It assumed PF0 always sits on PCI bus 1 and derived other PF bus numbers as pf + 1, but the AF device can be enumerated on a different bus. Use rvu->pdev->bus->number as the base bus instead, so each PF lookup uses pf + start on systems where RVU functions are on contiguous buses but do not start at bus 1. Fixes: e2fb373038654 ("octeontx2-af: Display CGX, NIX and PF map in debugfs.") Signed-off-by: Subbaraya Sundeep Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904085114.3385530-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72be1fd5d256dde748c0905c5e1749a119cad5bd 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 82c5df5d658461538586f289f26966bbb975ccee 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 6558b0d46c5941ed1aa67da8878e224c54239cc5 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 cc99d26b12431e4e4d0e346ec32764eb42c0aed9 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 3269a9b4409e9b493c48e8622f2f466aef014b70 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 7ced87834f3a58761d4bbcabf8326478548e6a54 Author: Lorenzo Bianconi Date: Fri Sep 4 12:32:55 2026 +0200 net: stmmac: initialize ptp_lock at probe time [ Upstream commit 0338c68e22abd2ee509ec2e32508a50896618c32 ] priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state. Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260904-stmmac-fix-ptp-clock-init-v1-1-df70eb1eb04d@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a256f9925288ef47de8febed5c38d5cc21340211 Author: Qingfang Deng Date: Tue Sep 8 15:21:31 2026 +0800 ppp_synctty: ensure a writeable skb header [ Upstream commit 8aaeb56aff2a557a88f83ae866da2c91ad247e59 ] ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header. Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260908072135.877364-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11a532aba48f05f0d61c2d9cba6d81b932862a4f 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 ab02236db66d4cf3c17ae7cc71dd178e52c560b1 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 9d6bce3953c25cbe57fe2f4721705fd307879662 Author: Marek Vasut Date: Sat Sep 5 15:02:32 2026 +0200 net: ks8851: Fix receiver error in 100BASE-TX mode following software power-down [ Upstream commit 66ef5adb75446627f8b6c26cd04f2adc86d4de56 ] KSZ8851 errata sheet DS80000716D-page 4 Module 3 [1] states that, when issuing a software power-down (PMECR[1:0] = 10) followed by a power-on (PMECR[1:0] = 00), the receiver circuit can fail to start properly preventing communication. The Transmitter will still send data, but no data will be received. The errata sheet also includes a workaround, which states that, it is recommended that the software power-down feature not be used. Implement that workaround and drop the entry into software power-down mode. The ks8851_write_mac_addr() calls entry into normal power-on mode at the very beginning of the function, therefore dropping the second call to enter software power-down mode is sufficient here. The ks8851_net_stop() can only be called after ks8851_net_start() was already called, and ks8851_net_start() also makes the MAC enter normal power-on mode, therefore it is also fine to drop the call to enter software power-down mode from ks8851_net_stop(). This will lead to a slight increase in power consumption, but it also fixes a sporadic reliability problem on at least KSZ8851-16MLL, which is where the problem was reported and this fix was tested. [1] https://ww1.microchip.com/downloads/en/DeviceDoc/80000716D.pdf Fixes: 3ba81f3ece3c ("net: Micrel KS8851 SPI network driver") Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260905130327.203851-1-marex@nabladev.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c39a902e160c1118d50432b2afaf34286ba69ac3 Author: Yicong Hui Date: Sun Jan 18 12:10:00 2026 +0000 net/micrel: Fix typos in micrel driver code comments [ Upstream commit c2b733da93bf607d6c6f925b4d40598e6bb516be ] Fix various typos and misspellings in code comments in the drivers/net/ethernet/micrel directory Signed-off-by: Yicong Hui Link: https://patch.msgid.link/20260118121001.136806-3-yiconghui@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 66ef5adb7544 ("net: ks8851: Fix receiver error in 100BASE-TX mode following software power-down") Signed-off-by: Sasha Levin commit 9eb43d0e5912b180f5318e1e085b24064a723958 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:46 2026 +0800 watchdog: msc313e: Sync timeout value if WDT was running at boot [ Upstream commit 01504d14e47b34779911250dd308a03f6ef681c2 ] If WDT was running at boot, the hardware timeout might be set to values other than the final software timeout. To be consistent, set the hardware timeout to match the final software timeout (i.e., after watchdog_init_timeout()) if WDT was running. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-8-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 20e564436f8d85e058d8c58c4738057efb933368 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:45 2026 +0800 watchdog: msc313e: Fix undefined behavior [ Upstream commit ab390021b2a3bb4cc875f28a6f76d13de90d7457 ] readw() returns a u16. Left shifting a u16 by 16 bits yields undefined behavior. Cast to u32 explicitly before the shift. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-7-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f9e5db6428ed49e42b9b5e019f568636fdf86376 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:44 2026 +0800 watchdog: msc313e: Fix spurious reset on suspend [ Upstream commit 4f6817c9eff4aa1078e16652d82e4b7ef4ffae3e ] If the hardware watchdog was started by the bootloader and the device is suspended before userspace opens it, the ping worker (from watchdog core) is frozen and the active hardware timer continues running. This leads to a spurious system reset. Check both watchdog_active() and watchdog_hw_running() when deciding whether to start or stop the watchdog during suspend and resume. Additionally, call watchdog_stop_ping_on_suspend() to ensure the ping worker be correctly paused and restarted during suspend and resume. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-6-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9a0cae4de8da3c0e29887fdc2c9218b99a8c2f48 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:43 2026 +0800 watchdog: msc313e: Enable clock before accessing hardware registers [ Upstream commit 3db2df24e7f11fb117718f6abe326628d91bc500 ] msc313e_wdt_probe() reads from hardware registers without ensuring the required clock is enabled. Furthermore, if the bootloader leaves the watchdog running, msc313e_wdt_probe() sets WDOG_HW_RUNNING without increasing the clock's reference count. While the clock is currently supplied as a fixed clock by the device tree (`xtal_div2` in arch/arm/boot/dts/sigmastar/mstar-v7.dtsi) which masks the physical issue, this still violates the API usage. Call clk_prepare_enable() before reading WDT registers. If the WDT is running, leave the clock enabled so the CCF reference counter is balanced. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-5-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 77ef2aa8b46876ca9935f32dd874c517ccf5d880 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:42 2026 +0800 watchdog: msc313e: Fix clock leak and spurious timer in settimeout() [ Upstream commit 3db30f315935c2fb0d95f46b7a593b5b4d3ec3d0 ] msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-4-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit db900bc7c0739e5505a84bebb1bff2c3f67860e3 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:41 2026 +0800 watchdog: msc313e: Avoid division by zero [ Upstream commit 3c73a37f5e40972ce26d8eeb98e8b938d719b069 ] clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-3-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 13e1398a58e98964c067b41fbd310f61baae2fe5 Author: David Arcari Date: Thu Sep 3 14:20:29 2026 -0400 watchdog: fix hrtimer start when pretimeout is zero [ Upstream commit 0fa37512eb747e4ffdcf367274f9e72845f1bca4 ] Per the watchdog API, a pretimeout value of 0 disables the feature. However, watchdog_hrtimer_pretimeout_start() fails to verify if the pretimeout is non-zero before arming the timer. This omission inadvertently starts the software pretimeout timer, which could result in the pretimeout handler executing incorrectly when the watchdog timeout is reached. Fix this by adding a check for wdd->pretimeout before calling hrtimer_start(), ensuring the disabled state is respected. Fixes: 7b7d2fdc8c3e ("watchdog: Add hrtimer-based pretimeout feature") Signed-off-by: David Arcari Link: https://patch.msgid.link/20260903182029.936030-1-darcari@redhat.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0112aa02c7847314be599d68783d50c7e228a694 Author: Nicolai Buchwitz Date: Mon Sep 7 23:08:55 2026 +0200 net: macb: destroy the phylink instance on the probe error path [ Upstream commit 7d059f390750152b9bd69df934198651b94fc26d ] macb_mii_init() creates a phylink instance on both of its success paths, but the probe unwind frees the netdev without destroying it, so a failing macb_alloc_tieoff() or register_netdev() leaks the instance. Destroy it at err_out_unregister_mdio, which is only reachable once macb_mii_init() has succeeded, so bp->phylink is valid there. Fixes: 7897b071ac3b ("net: macb: convert to phylink") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260907210856.1673589-2-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc654a72a8d979db15e2773a481e931abaf5a9e8 Author: Luiz Augusto von Dentz Date: Mon Aug 31 12:13:10 2026 -0400 Bluetooth: btusb: Fix UAF of btusb_data by rx_work [ Upstream commit 1c12c3117639e78940959d956519c758c57d0849 ] btusb_close() and btusb_flush() cancel data->rx_work with the asynchronous cancel_delayed_work(), so if btusb_rx_work() is already running on another CPU it keeps running after the cancel returns. btusb_disconnect() calls hci_unregister_dev(), which invokes btusb_close(), and then frees the btusb_data. A still running btusb_rx_work() then dereferences the freed data: while ((skb = skb_dequeue(&data->acl_q))) data->recv_acl(data->hdev, skb); Use cancel_delayed_work_sync() instead. In btusb_close() the cancel also has to happen after btusb_stop_traffic(), otherwise an URB completion racing with the cancel can requeue the work right after it has been waited for. Fixes: 800fe5ec302e ("Bluetooth: btusb: Add support for queuing during polling interval") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 09a7cdf8fffb065a8aa30cfa604ff4a65cbf04c9 Author: Jacob Keller Date: Mon Jul 6 16:31:17 2026 -0700 ice: add missing xa_destroy for sched_node_ids [ Upstream commit 53432c4c3e869076350aef319534431af8ba99c1 ] Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code. Fixes: 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") Signed-off-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8249fea1989426c86f8612204f351ef507062370 Author: HyeongJun An Date: Tue Sep 8 22:41:53 2026 +0900 ALSA: hda: Report a change when only the channel status bytes move [ Upstream commit 7284788743121ec8bed556b00f830dc52ad9955d ] The put() callback of "IEC958 Playback Default" returns whether the converted register value moved. The convert_from_spdif_status() helper reads part of the first two channel status bytes and none of the last two, while the get() callback returns all four. So a write that lands only in the bits it does not read changes what userspace reads back and reports no change. Of the 31 bits above the mode bit, 20 are such bits in consumer mode and 29 in professional mode. The core notifies only on a positive return. Toggling status[2] bit 0 on an HDA HDMI codec moves the read-back from 04 00 00 00 to 04 00 01 00 with no event. Toggling the non-audio bit in status[0] gives one. Compare the stored status as well, the way the ac97 code does. The write to the codec stays gated on the converted value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260908134153.1614273-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5fe0548ba8531b3f515f4ea4f9a3e850b04ae12e Author: Takashi Iwai Date: Wed Aug 27 09:28:47 2025 +0200 ALSA: hda/common: Use guard() for mutex locks [ Upstream commit 62dd3851d2450a5fb2259da1f0391b5870e07577 ] Replace the manual mutex lock/unlock pairs with guard(). Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250827072916.31933-8-tiwai@suse.de Stable-dep-of: 728478874312 ("ALSA: hda: Report a change when only the channel status bytes move") Signed-off-by: Sasha Levin commit 86da58ff633f44c30b4a3bcfdbd0ff95309d7096 Author: Takashi Iwai Date: Wed Aug 27 09:28:45 2025 +0200 ALSA: hda/common: Use cleanup macros for PM controls [ Upstream commit 8dad6b3dac2794c52d63b2336138392eddc17936 ] The new macro CLASS(snd_hda_power_pm) can replace the manual snd_hda_power_up_pm() and _down() calls gracefully. A part of the code in codec_exec_verb() is factored out to a function, so that the auto-cleanup can be well scoped. Merely cleanups and no functional changes. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250827072916.31933-6-tiwai@suse.de Stable-dep-of: 728478874312 ("ALSA: hda: Report a change when only the channel status bytes move") Signed-off-by: Sasha Levin commit 149f635080bf9dba464c559071f62ee9adf3428f Author: Takashi Iwai Date: Wed Aug 27 09:28:41 2025 +0200 ALSA: hda: Introduce auto cleanup macros for PM [ Upstream commit 5d8c9c987fbdd65677315198c2b1f35a440d7cdf ] The temporary power up/down of the codec via snd_hda_power_up() and _down() (or snd_hda_power_up_pm() and _down_pm()) is seen in various places. This patch introduces simple auto-cleanup macros for those call patterns, so that the drivers don't have to call the corresponding power-down calls explicitly. Namely, err = snd_hda_power_up(codec); if (err < 0) return err; .... snd_power_down(codec); can drop the *_down() call by replacing with CLASS(snd_hda_power, pm)(codec); if (pm.err < 0) return pm.err; Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250827072916.31933-2-tiwai@suse.de Stable-dep-of: 728478874312 ("ALSA: hda: Report a change when only the channel status bytes move") Signed-off-by: Sasha Levin commit 39e3fc30bbb125c51e18ac7360ef30dded73a1b0 Author: Karl Mehltretter Date: Sat Sep 5 10:03:44 2026 +0200 drm/logicvc: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER [ Upstream commit f97802dd98b27e45c04293f9926f07642578b23f ] CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option"). When commit 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") later renamed the select in this Kconfig to CONFIG_DRM_KMS_DMA_HELPER, no symbol of that name existed, and git log -S finds no Kconfig file that has defined one since. The select is silently ignored. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080344.34077-1-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit 563b2b144a6e4364ca464100a533f4539bf3d6dc 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 8053cced6ac880b6be83e0d6c6fa79fa1eb7838c 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 54a43c1d208d72646acf62f4ddf02c73eb726bfe 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 27b5753077d1cfda5fe201d2ba602de76a9a09b1 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 80ceab390a7d5c9568950df39e79047418d49b85 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 aa339ac334d4e51f43af9d2901e6faf11ffd981e 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 17405d920c8621a6643f443f8f86157c9b603198 Author: Alice Mikityanska Date: Tue Sep 1 22:57:14 2026 +0300 net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward [ Upstream commit 199271ebc71c1e0913b2fad988a7bff330a8828a ] Commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") dropped the IP6_MAX_MTU clamp that used to be present in ip6_mtu(). A similar IPv4 commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and ip_dst_mtu_maybe_forward") preserves the IP_MAX_MTU clamp. Restore the upper bound in the IPv6 flow to avoid potential 16-bit overflows in forwarding paths. Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") Signed-off-by: Alice Mikityanska Suggested-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-5-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ae729b1f8ab81d1244061872db2fb0ebb110d2a Author: Karl Mehltretter Date: Sat Sep 5 17:20:58 2026 +0200 virtio_input: stop callbacks before unregistering input device [ Upstream commit d7808b37da0a619cf1fa541c2384e783fecc2480 ] virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports. Fixes: 271c865161c5 ("Add virtio-input driver.") Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Michael S. Tsirkin Message-ID: <20260905152059.89560-3-kmehltretter@gmail.com> Signed-off-by: Sasha Levin commit 087b9ee4d36968329c846e6846e4e50f66532888 Author: Xiong Weimin Date: Wed Aug 5 11:29:31 2026 +0800 virtio_input: reset device if input_register_device() fails [ Upstream commit 81489b32a21c9360f8750d1fb600155d27452e19 ] Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down. Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues. Fixes: 271c865161c5 ("Add virtio-input driver.") Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260805032931.1606652-1-xiongweimin@kylinos.cn> Signed-off-by: Sasha Levin commit 00130f6a8e1925cb115a21aa84de60817afd3183 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 36ef4d8527f71648f00347f6ba759f0b7e5e0977 Author: Linfeng Sun Date: Tue Sep 1 17:48:00 2026 +0800 vdpa_sim_blk: reject out-of-range sector starts [ Upstream commit 0a8693f00c408d85f086ad85d29e7030bf1e2055 ] vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance. Fixes: 7d189f617f83 ("vdpa_sim_blk: implement ramdisk behaviour") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260901094800.25475-1-linfeng.sun.dev@gmail.com> Signed-off-by: Sasha Levin commit 4fde085eb839fbb39c25cbba5d2a091ded394877 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 8f6cfc3eca79b8e108d0823756101e2f4f9d811f 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 e33e70f73a72222fec48a5d3ea5d2b2e1c55f667 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 2231b621ee7fb69158ac21311f8175a6e068e550 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 54eb1889bcbf75d289ece504d0fdc243d1e24843 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 291685fc8d2e4cf75ed3a23c810883653f407f46 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 222e215eb27232f831f906da4d16387447085370 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 02bd1c98606fe7cd575039b96ade8c7568f9cb63 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 dbd3effcbdb85394d3c4bd5ee9df785a44303333 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 afa224cabc0132ca414b9141b1a919ca2d318cd0 Author: Vineeth Karumanchi Date: Wed Sep 2 15:58:36 2026 +0530 net: macb: fix NULL pointer dereference on unbind with fixed-link [ Upstream commit 38b6be101006d3e7af972999f45d4f1e8250587a ] When the device tree describes a fixed-link and has no "mdio" child node, macb_mii_init() returns early without allocating the MDIO bus, leaving bp->mii_bus as NULL. Two cleanup paths then dereference this NULL bus: 1. On driver unbind, macb_remove() unconditionally calls mdiobus_unregister(bp->mii_bus), which oopses: Unable to handle kernel NULL pointer dereference at virtual address 00000000000004a8 pc : mdiobus_unregister+0x14/0xa4 lr : macb_remove+0x38/0xa4 Call trace: mdiobus_unregister+0x14/0xa4 (P) macb_remove+0x38/0xa4 platform_remove+0x20/0x30 device_release_driver_internal+0x1c8/0x224 unbind_store+0xb4/0xbc 2. On the probe error path in macb_probe(), reached when macb_mii_init() has succeeded but a subsequent step fails, the err_out_unregister_mdio label runs the same unconditional cleanup. mdiobus_unregister() and mdiobus_free() do not guard against a NULL bus, so guard the calls in both macb_remove() and the probe error path. Fixes: d0c3601f2c4e ("net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY") Signed-off-by: Vineeth Karumanchi Reviewed-by: Xuanqiang Luo Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260902102836.2019355-1-vineeth.karumanchi@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bac921c5819632d790f804fdd395f5e85ff28b48 Author: Théo Lebrun Date: Thu Oct 23 18:22:54 2025 +0200 net: macb: rename bp->sgmii_phy field to bp->phy [ Upstream commit 3f7e51cd5fbf4d970b14956ee9464515bb40666f ] The bp->sgmii_phy field is initialised at probe by init_reset_optional() if bp->phy_interface == PHY_INTERFACE_MODE_SGMII. It gets used by: - zynqmp_config: "cdns,zynqmp-gem" or "xlnx,zynqmp-gem" compatibles. - mpfs_config: "microchip,mpfs-macb" compatible. - versal_config: "xlnx,versal-gem" compatible. Make name more generic as EyeQ5 requires the PHY in SGMII & RGMII cases. Drop "for ZynqMP SGMII mode" comment that is already a lie, as it gets used on Microchip platforms as well. And soon it won't be SGMII-only. Reviewed-by: Andrew Lunn Reviewed-by: Maxime Chevallier Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-4-af509422c204@bootlin.com Signed-off-by: Paolo Abeni Stable-dep-of: 38b6be101006 ("net: macb: fix NULL pointer dereference on unbind with fixed-link") Signed-off-by: Sasha Levin commit 9417b418e4628fc83c7c74ed9ddd28f9abc6f062 Author: Allen Pais Date: Tue Feb 27 19:10:37 2024 +0000 workqueue: Introduce from_work() helper for cleaner callback declarations [ Upstream commit 60b2ebf48526567b53e0188dbd1a4df8e646bcc1 ] To streamline the transition from tasklets to worqueues, a new helper function, from_work(), is introduced. This helper, inspired by existing from_() patterns, utilizes container_of() and eliminates the redundancy of declaring variable types, leading to more concise and readable code. The modified code snippet demonstrates the enhanced clarity achieved with from_wq(): void callback(struct work_struct *w) { - struct some_data_structure *local = container_of(w, struct some_data_structure, work); + struct some_data_structure *local = from_work(local, w, work); This change aims to facilitate a smoother transition and uphold code quality standards. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git disable_work-v3 Signed-off-by: Allen Pais Signed-off-by: Tejun Heo Stable-dep-of: 38b6be101006 ("net: macb: fix NULL pointer dereference on unbind with fixed-link") Signed-off-by: Sasha Levin commit 8b8d782c3b96376217087767dcf662cd3d25f226 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 23fea7e6736b2e1c6f6f2f05cccf33d36834da73 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 d8d553754d9237931c461aaae68d51b9be907710 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 2c6dd9fc86d446a03728c43f3b96d9ae29aa058f 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 0692ce5a528df450d64e9f819054177e9d91076f 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 8fd98e56c41f79278eeb67512c28d7abc175bcf4 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 7211d0243bf3ccde23bfe65a0d83f40d95134928 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 2196f9d3358b00fcb28835a5fde14071f51ecb96 Author: Lama Kayal Date: Wed Sep 2 22:38:54 2026 +0300 net/mlx5: E-Switch, prevent mc_list repopulation during vport disable [ Upstream commit c0c6f4ba8a37688f7b4d4044898d88f0450d44c2 ] In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list. Fixes: 922f56e9a795 ("net/mlx5: Fix steering rules cleanup") Signed-off-by: Lama Kayal Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193854.3669035-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 92f581cac93a71723456ac79ef54d9f60a251b42 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 308e1cbb0d9712081f90860fe839ccb47bc196ee Author: Carolina Jubran Date: Wed Sep 2 22:33:41 2026 +0300 net/mlx5e: Fix use-after-free race in sample_restore_put() [ Upstream commit af3aef0245abbab5e9f6302e7a7d6407187afb71 ] Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed. Fixes: 36a3196256bf ("net/mlx5e: TC, Add sampler restore handle API") Signed-off-by: Carolina Jubran Reviewed-by: Shahar Shitrit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193341.3668809-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54338d6b65f68c8c46ac49b2a3fece46cc550e6c 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 d6c603d9f350a4ba2e2fa84144f079019d9f778a 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 96a27a3e64e7c87abade03fb2ad04ed66992a89a Author: Weiming Shi Date: Wed Sep 2 23:52:31 2026 +0800 net/sched: defer qdisc freeing after failed creation [ Upstream commit e6662f2100f8d33b0f4d0047c219efd6bba186ea ] An RTM_NEWQDISC request can make clsact bind a populated shared ingress block during ->init(), publishing an embedded mini_Qdisc to lockless readers. If the same request has an invalid TCA_RATE, estimator setup fails after ->init(); the unwind removes the pointer but synchronously frees its containing qdisc while tc_run() may still hold it. Retire failed qdiscs through the same RCU helper as normal destruction. Inline the synchronous free into the callback now that no direct callers remain. Fixes: 51ab2994c387 ("net: sched: allow ingress and clsact qdiscs to share filter blocks") Reported-by: Xiang Mei Link: https://lore.kernel.org/netdev/20260805102505.740806-1-david.lee@trailofbits.com/ Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260902155231.2149915-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 061ecb633ee808e0e24fd8ee038b881d11c50fc4 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 c8d4060610c69645733c92d94fceb4b93808ac4d 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 c8f29af91e0830fdabc9aa1eb1a0f898ce1bc603 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 00520cdd21ea6a9b5dc8d53bbd241620d2059554 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 3827988cd9c1f1ac4b2407602d9ba9d8323f5e41 Author: Viswajith Murali Date: Tue Sep 1 15:13:17 2026 +0530 octeontx2-af: mcs: Clear stale X2P calibration state before calibration [ Upstream commit 1f29543126dde307e8b5fb6a740c54e59deaa2ff ] Some firmware versions leave MCSX_MIL_GLOBAL bit 5 set on boot. If the bit is already set when the driver attempts X2P calibration, the hardware sees no rising edge and calibration never triggers. Clear the bit and wait briefly before starting calibration to ensure a clean rising edge. Fixes: ca7f49ff8846 ("octeontx2-af: cn10k: Introduce driver for macsec block.") Signed-off-by: Nitin Shetty J Signed-off-by: Viswajith Murali Link: https://patch.msgid.link/20260901094318.1395356-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 609c4378f212cf580aae02250f1146caf63d873f 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 f2cf4ef2d94fc15fd2e21c131fc1ab3f76125bf4 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 342b3b10c91a838550b0118a1e7367349609e0d2 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 704319510af2179cf03955747d714ab291075c25 Author: Ido Schimmel Date: Thu Sep 3 11:02:59 2026 +0300 nexthop: Initialize extack in remove_nh_grp_entry() [ Upstream commit 5bd9e4e7cdaa03879e9b73b12ab52cceb1edd55b ] remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee ("nexthop: initialize extack in nh_res_bucket_migrate()"). Fixes: 833a1065eeb1 ("nexthop: Emit a notification when a nexthop group is reduced") Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260903080259.10378-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7cf90a27e2af95445b7cdcd3c8d22476e57a45f9 Author: Jiayuan Chen Date: Fri Sep 4 15:37:39 2026 +0800 selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0 [ Upstream commit 5e8c349bc8d790fe031a4332e502f5d4f9878644 ] The bpf_nf test allocs a ct, sets snat and dnat with random addr and port via bpf_ct_set_nat_info(), then looks the ct up and checks the reply tuple against what was set. The port comes from bpf_get_prandom_u32() and can be 0. For bpf_ct_set_nat_info(), port 0 means "port not specified", so only the addr is mapped and the kernel keeps the original port. The check then compares that port with 0 and fails, which shows up as a flaky "Test for source natting" failure in CI [1][2]. Keep the random port in 1..65535 so it is always specified. [1] https://github.com/kernel-patches/bpf/actions/runs/33830002889/job/100893868791 [2] https://github.com/kernel-patches/bpf/actions/runs/33829976794/job/100893220999 Fixes: b06b45e82b59 ("selftests/bpf: add tests for bpf_ct_set_nat_info kfunc") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260904073745.363314-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2af4d8146c6702f579178094ba44e160790438d7 Author: Brad Cowie Date: Wed May 22 17:07:12 2024 +1200 selftests/bpf: Update tests for new ct zone opts for nf_conntrack kfuncs [ Upstream commit a87f34e742d279d54d529e4bc4763fdaab32a466 ] Add test for allocating and looking up ct entry in a non-default ct zone with kfuncs bpf_{xdp,skb}_ct_alloc and bpf_{xdp,skb}_ct_lookup. Add negative tests for looking up ct entry in a different ct zone to where it was allocated and with a different direction. Update reserved test for old struct definition to test for ct_zone_id being set when opts size isn't NF_BPF_CT_OPTS_SZ (16). Signed-off-by: Brad Cowie Link: https://lore.kernel.org/r/20240522050712.732558-2-brad@faucet.nz Signed-off-by: Martin KaFai Lau Stable-dep-of: 5e8c349bc8d7 ("selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0") Signed-off-by: Sasha Levin commit 7bf23cf7c9c0e0b5e638e497cdc0ec3f223742cc Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:49 2026 +0200 bpf: Mark bpf_btf_find_by_name_kind() as sleepable [ Upstream commit 620614bf7672130c43b3cff375525a2202f61979 ] When bpf_btf_find_by_name_kind() finds a type in module BTF, it returns a new BTF object fd through __btf_new_fd(). This reaches anon_inode_getfd(), which can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks. The fd allocation can then sleep in softirq context and install the fd into the interrupted task. Mark the helper as sleepable. This preserves calls from the main body of a sleepable syscall program while rejecting calls from its non-sleepable regions. Fixes: 3d78417b60fb ("bpf: Add bpf_btf_find_by_name_kind() helper.") Reported-by: Sashiko Link: https://lore.kernel.org/bpf/20260903155150.D57251F000E9@smtp.kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5854fc2158779196895ef6e4a14a52382ad8c181 Author: Yonghong Song Date: Wed Nov 23 21:32:11 2022 -0800 bpf: Introduce might_sleep field in bpf_func_proto [ Upstream commit 01685c5bddaa6df3d662c8afed5e5289fcc68e5a ] Introduce bpf_func_proto->might_sleep to indicate a particular helper might sleep. This will make later check whether a helper might be sleepable or not easier. Acked-by: Martin KaFai Lau Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20221124053211.2373553-1-yhs@fb.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 620614bf7672 ("bpf: Mark bpf_btf_find_by_name_kind() as sleepable") Signed-off-by: Sasha Levin commit 68885c606a6e41dd4d3fe72f11241a6a438246ed Author: Cezary Rojewski Date: Wed Sep 2 10:18:08 2026 +0200 ASoC: Intel: avs: Clean up the bus when fetching ML caps fails [ Upstream commit 559ea14b7ae7c7562b48759fa545b64958f35b73 ] snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope. Fixes: 1affc44ea5dd ("ASoC: Intel: avs: PCI driver implementation") Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ef17c8e320862543b43ae08226b05d04a30d0314 Author: Pierre-Louis Bossart Date: Wed Oct 19 11:21:10 2022 -0500 ALSA/ASoC: hda: ext: add 'ext' prefix to snd_hdac_link_free_all [ Upstream commit 7f05ca9a7467f05b8703b37bdc1ddddd0e9f8876 ] No functionality change, just prefix addition to clearly identify that the helper only applies to the 'ext' part for Intel platforms. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20221019162115.185917-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Stable-dep-of: 559ea14b7ae7 ("ASoC: Intel: avs: Clean up the bus when fetching ML caps fails") Signed-off-by: Sasha Levin commit e0d6a06171633d3ee3f7a39b57e5c845fb2b79f2 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 62b00074b58ccf43f61f70f2cfcac80937b530c6 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 b6cd6f1664a0bc8038b9baa7e6f5fe8e4142d056 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 92e4fe2349cbe8e37b91a865e6b46e79ffd697e7 Author: HyeongJun An Date: Thu Sep 3 21:38:32 2026 +0900 selftests/alsa: Fix the step check for INTEGER controls [ Upstream commit 8efd5f623c63584c2e284a837a7795d95a0491cb ] The modulo sits inside the subtraction, so the check evaluates int_val - (min % step) rather than (int_val - min) % step. The INTEGER64 branch below it is parenthesised correctly. The written form passes only when the value equals min % step, and such a value is always on a step boundary, so it never misses a real violation. It only reports valid values as invalid. snd-aloop declares step 1 on four controls, so every non-zero value on them is reported. Before: # PCM Rate Shift 100000.0 value 100000 invalid for step 1 minimum 80000 # Totals: pass:660 fail:101 xfail:0 xpass:0 skip:296 error:0 After, same card, nothing else changed: # Totals: pass:740 fail:21 xfail:0 xpass:0 skip:296 error:0 Eighteen files under sound/ declare a non-zero step. Fixes: 5aaf9efffc57 ("kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260903123832.97377-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cbf74caf954a779350b9139b1404fd30008e6dc1 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 4980ce260205001d582a7b3cb5eab29877777fbc 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 32e21bcf4b5b11454bf57c4bb3bf019b71512ace 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 a05790cb4ff03f797d76906990b148d83f63e7a3 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 4c5ce56028040e88ab1e535f0b5ff68c500038fe 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 b7dc5da660eb5ffa7f7b4d33f2c74cb71c6edd6c 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 65117829524b4b8b8f9bbfc7a8cde2770f9c7539 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 5a806ed1eb46850ca4159a18b2a8c4b70f0c1341 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 384739c631aa6749356ba062d6b7c9a484a733f6 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 314c8caa9cb64ad60c5b969fe9a3e2dcdccf156f Author: Eduard Zingerman Date: Wed Sep 2 16:36:57 2026 -0700 bpf: reject BPF_PSEUDO_FUNC reference to the main program [ Upstream commit 374b2c5561db80fcdd7cdce44af37a49416f61c7 ] fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260902233658.1186477-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a2510fcaad92b09b34574c97e8356234c6a84a9a 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 0cfb96a118c5c6d46d7a1cfdfa18355ad734ca79 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 f487b5788f15c6c32a219ed1480d25c93fc18d30 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 7ce02d52548b672795511c2cac8da6ec79ac8877 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 cb9e5c1fcee3830f4b7b318e941064bae48faee8 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 35ef3271173428129be094aae4b6f5fb99d06133 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 f984b08773f5c64be65efbef528c83797cbd2961 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 286ca3742020d3e061f02db9d8b7f6b9a4ccf98c Author: Linus Walleij Date: Fri Jun 19 22:27:10 2026 +0200 mfd: db8500-prcmu: Fold dbx500 header into db8500 [ Upstream commit b8bc38bcecb77880a802d0430862b023c0aa7392 ] Move the DBx500 PRCMU definitions into the DB8500 PRCMU header and delete the wrapper header. Convert users of simple PRCMU wrappers to call the DB8500 helpers directly. The dbx500-prcmu.h header was the result of an earlier attempt to abstract several DBx5x SoC PRCMU units to use the same abstract header. They are deleted from the kernel and this is not just causing maintenance burden and build errors. The stub code is using -ENOSYS in a way checkpatch complains about so replace these with -EINVAL while we're at it. Assisted-by: Codex:gpt-5-5 Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/ Signed-off-by: Linus Walleij Acked-by: Brian Masney Acked-by: Guenter Roeck Acked-by: Mark Brown Link: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/ Link: https://patch.msgid.link/20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org Signed-off-by: Lee Jones Stable-dep-of: 66ec63e7a90b ("ASoC: ux500: Deassert the MSP reset during probe") Signed-off-by: Sasha Levin commit 3843693618232d86dd6572e6053bd01c3ac50c86 Author: Kees Cook Date: Thu Jul 17 16:25:10 2025 -0700 arm: Handle KCOV __init vs inline mismatches [ Upstream commit 2424fe1cac4fc8ea0520ba22ede7544c3ddc8dd1 ] When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For arm this exposed several places where __init annotations were missing but ended up being "accidentally correct". Fix these cases and force several functions to be inline with __always_inline. Acked-by: Nishanth Menon Acked-by: Lee Jones Reviewed-by: Nishanth Menon Link: https://lore.kernel.org/r/20250717232519.2984886-5-kees@kernel.org Signed-off-by: Kees Cook Stable-dep-of: 66ec63e7a90b ("ASoC: ux500: Deassert the MSP reset during probe") Signed-off-by: Sasha Levin commit 699752231b6db89d60a67521d7d19c9c74678b40 Author: Zijun Hu Date: Fri Feb 21 05:02:20 2025 -0800 mfd: db8500-prcmu: Remove needless return in three void APIs [ Upstream commit c105c555f8b4fd57b09439806b43b97ebc240ee2 ] Remove needless 'return' in the following void APIs: prcmu_early_init() prcmu_system_reset() prcmu_modem_reset() Since both the API and callee involved are void functions. Signed-off-by: Zijun Hu Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250221-rmv_return-v1-15-cc8dff275827@quicinc.com Signed-off-by: Lee Jones Stable-dep-of: 66ec63e7a90b ("ASoC: ux500: Deassert the MSP reset during probe") Signed-off-by: Sasha Levin commit 79a75b7086dab8c2b0a425df3e11e30d3ccfab70 Author: YueHaibing Date: Thu Jul 20 22:37:38 2023 +0800 mfd: db8500-prcmu: Remove unused inline functions [ Upstream commit 2dfe293bcde2d302c045d0cd536ccb15f86385d2 ] Since commit b0e846248de5 ("mfd: db8500-prcmu: Remove dead code for a non-existing config") these inline helpers also no need any more. Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20230720143738.13996-1-yuehaibing@huawei.com Signed-off-by: Lee Jones Stable-dep-of: 66ec63e7a90b ("ASoC: ux500: Deassert the MSP reset during probe") Signed-off-by: Sasha Levin commit 1171a109392b2031115bed43b4ccc72126395f9e 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 0c5b04458502e588218122230d951f6528ce958a 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 803d8daffce89de969c3448c50507fa89883d009 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 8ab65e4319a0fa371060912a4b4ac9c2f0126933 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 e8f88cfebe75866f0639e6c5b93a4c16496ff10e 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 1c9d664e2e067fca69e5a41d68e23bbc66a583fe Author: Eric Dumazet Date: Mon Aug 24 15:51:29 2026 +0000 locking/lockdep: Invalidate stale class_cache entries for zapped classes [ Upstream commit 02c6be7d675b21d81f0ba3a524346850a8c0e3bf ] syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in hlock_class() due to an invalid class_idx: WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203 Workqueue: wg-crypt-wg0 wg_packet_tx_worker RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline] RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203 Call Trace: lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886 _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173 tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291 tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325 ... When a lock class is zapped (e.g. during module unload or key unregistration), zap_class() clears the class's bit in lock_classes_in_use and removes it from the class hash table. However, existing lockdep_map instances embedded in data structures may still retain a pointer to the zapped class in their class_cache[] array. When __lock_acquire() subsequently runs on such a lock, it finds lock->class_cache[subclass] != NULL, skipping register_lock_class() and assigning hlock->class_idx to the index of the zapped class. When check_wait_context() or hlock_class() inspects the held_lock, it finds !test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if the zapped slot is subsequently re-allocated to an unrelated lock key, the stale class_cache entry would erroneously match the unrelated class (ABA issue). Add lock_class_cache_is_valid() to validate that the cached class is within lock_classes bounds, still allocated in lock_classes_in_use (using uninstrumented arch_test_bit() in __always_inline context so it is safe in noinstr contexts like match_held_lock()), and that class->key matches the expected subkey (taking lockdep_set_subclass() overrides into account). Also use READ_ONCE()/WRITE_ONCE() when accessing class_cache[]. If the entry is invalid or stale, fall back to register_lock_class() / look_up_lock_class(). Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") Closes: https://lore.kernel.org/netdev/6a8c66dc.4d75e56a.c9a88.0050.GAE@google.com/T/#u Reported-by: syzbot+2d770620059281e225a4@syzkaller.appspotmail.com Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Eric Dumazet Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260824155129.676096-1-edumazet@google.com Signed-off-by: Sasha Levin commit 90137e19fbb54def7f9cedc583ac2523dfbe7c3d Author: Kent Overstreet Date: Tue May 9 15:58:46 2023 -0400 lockdep: Add lock_set_cmp_fn() annotation [ Upstream commit eb1cfd09f788e39948a82be8063e54e40dd018d9 ] This implements a new interface to lockdep, lock_set_cmp_fn(), for defining a custom ordering when taking multiple locks of the same class. This is an alternative to subclasses, but can not fully replace them since subclasses allow lock hierarchies with other clasees inter-twined, while this relies on pure class nesting. Specifically, if A is our nesting class then: A/0 <- B <- A/1 Would be a valid lock order with subclasses (each subclass really is a full class from the validation PoV) but not with this annotation, which requires all nesting to be consecutive. Example output: | ============================================ | WARNING: possible recursive locking detected | 6.2.0-rc8-00003-g7d81e591ca6a-dirty #15 Not tainted | -------------------------------------------- | kworker/14:3/938 is trying to acquire lock: | ffff8880143218c8 (&b->lock l=0 0:2803368){++++}-{3:3}, at: bch_btree_node_get.part.0+0x81/0x2b0 | | but task is already holding lock: | ffff8880143de8c8 (&b->lock l=1 1048575:9223372036854775807){++++}-{3:3}, at: __bch_btree_map_nodes+0xea/0x1e0 | and the lock comparison function returns 1: | | other info that might help us debug this: | Possible unsafe locking scenario: | | CPU0 | ---- | lock(&b->lock l=1 1048575:9223372036854775807); | lock(&b->lock l=0 0:2803368); | | *** DEADLOCK *** | | May be due to missing lock nesting notation | | 3 locks held by kworker/14:3/938: | #0: ffff888005ea9d38 ((wq_completion)bcache){+.+.}-{0:0}, at: process_one_work+0x1ec/0x530 | #1: ffff8880098c3e70 ((work_completion)(&cl->work)#3){+.+.}-{0:0}, at: process_one_work+0x1ec/0x530 | #2: ffff8880143de8c8 (&b->lock l=1 1048575:9223372036854775807){++++}-{3:3}, at: __bch_btree_map_nodes+0xea/0x1e0 [peterz: extended changelog] Signed-off-by: Kent Overstreet Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20230509195847.1745548-1-kent.overstreet@linux.dev Stable-dep-of: 02c6be7d675b ("locking/lockdep: Invalidate stale class_cache entries for zapped classes") Signed-off-by: Sasha Levin commit a4f058157cc1e2a94849de694614d60988d965f9 Author: Boqun Feng Date: Fri Jan 13 15:57:22 2023 -0800 locking/lockdep: Improve the deadlock scenario print for sync and read lock [ Upstream commit 0471db447cb7de56bbe2fedd9256b4d2b8ef642a ] Lock scenario print is always a weak spot of lockdep splats. Improvement can be made if we rework the dependency search and the error printing. However without touching the graph search, we can improve a little for the circular deadlock case, since we have the to-be-added lock dependency, and know whether these two locks are read/write/sync. In order to know whether a held_lock is sync or not, a bit was "stolen" from ->references, which reduce our limit for the same lock class nesting from 2^12 to 2^11, and it should still be good enough. Besides, since we now have bit in held_lock for sync, we don't need the "hardirqoffs being 1" trick, and also we can avoid the __lock_release() if we jump out of __lock_acquire() before the held_lock stored. With these changes, a deadlock case evolved with read lock and sync gets a better print-out from: [...] Possible unsafe locking scenario: [...] [...] CPU0 CPU1 [...] ---- ---- [...] lock(srcuA); [...] lock(srcuB); [...] lock(srcuA); [...] lock(srcuB); to [...] Possible unsafe locking scenario: [...] [...] CPU0 CPU1 [...] ---- ---- [...] rlock(srcuA); [...] lock(srcuB); [...] lock(srcuA); [...] sync(srcuB); Signed-off-by: Boqun Feng Signed-off-by: Paul E. McKenney Acked-by: Peter Zijlstra (Intel) Signed-off-by: Boqun Feng Stable-dep-of: 02c6be7d675b ("locking/lockdep: Invalidate stale class_cache entries for zapped classes") Signed-off-by: Sasha Levin commit cfd49118189902c59672910d7f67443d01a3764c Author: Boqun Feng Date: Thu Jan 12 22:59:53 2023 -0800 locking/lockdep: Introduce lock_sync() [ Upstream commit 2f1f043e7bea3fbf4c1869df2f7a0312bc8ca2bf ] Currently, functions like synchronize_srcu() do not have lockdep annotations resembling those of other write-side locking primitives. Such annotations might look as follows: lock_acquire(); lock_release(); Such annotations would tell lockdep that synchronize_srcu() acts like an empty critical section that waits for other (read-side) critical sections to finish. This would definitely catch some deadlock, but as pointed out by Paul Mckenney [1], this could also introduce false positives because of irq-safe/unsafe detection. Of course, there are tricks could help with this: might_sleep(); // Existing statement in __synchronize_srcu(). if (IS_ENABLED(CONFIG_PROVE_LOCKING)) { local_irq_disable(); lock_acquire(); lock_release(); local_irq_enable(); } But it would be better for lockdep to provide a separate annonation for functions like synchronize_srcu(), so that people won't need to repeat the ugly tricks above. Therefore introduce lock_sync(), which is simply an lock+unlock pair with no irq safe/unsafe deadlock check. This works because the to-be-annontated functions do not create real critical sections, and there is therefore no way that irq can create extra dependencies. [1]: https://lore.kernel.org/lkml/20180412021233.ewncg5jjuzjw3x62@tardis/ Signed-off-by: Boqun Feng Acked-by: Waiman Long Signed-off-by: Paul E. McKenney [ boqun: Fix typos reported by Davidlohr Bueso and Paul E. Mckenney ] Acked-by: Peter Zijlstra (Intel) Signed-off-by: Boqun Feng Stable-dep-of: 02c6be7d675b ("locking/lockdep: Invalidate stale class_cache entries for zapped classes") Signed-off-by: Sasha Levin commit 4dfe8ceb5ff4ca0f81f9b95b20f4cf3a88f69b96 Author: Leo Yan Date: Tue Aug 25 11:37:06 2026 +0100 perf/core: Skip empty AUX records with only format flags [ Upstream commit 8a7f5b5e860b5c113ca99acd5b1e9074f5c5af3c ] perf_aux_output_end() emits a PERF_RECORD_AUX when the recorded size is nonzero or when any flag other than PERF_AUX_FLAG_OVERWRITE is set. PMU format flags describe how an AUX payload is encoded. TRBE driver sets PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW for raw trace buffers, causing an AUX record to be emitted even when no trace data. This is noticeable when tracing a task with strace. Ptrace stops repeatedly end empty AUX transactions, producing many zero-sized PERF_RECORD_AUX records. For example: perf record -e cs_etm//u -m,128M -- strace ls perf script -D 2>&1 | awk '/PERF_RECORD_AUX offset/ { for (i = 1; i <= NF; i++) if ($i == "size:" && $(i + 1) == "0") count++ } END { print count }' 165 This recording contains 165 zero-sized AUX records which provide no useful information to userspace. Ignore PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK, together with PERF_AUX_FLAG_OVERWRITE, when deciding whether an empty AUX record is useful. Zero-sized records carrying TRUNCATED, PARTIAL or COLLISION are still emitted. Fixes: 547b60988e63 ("perf: aux: Add flags for the buffer format") Reported-by: Tamas Petz Signed-off-by: Leo Yan Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260825-perf_core_fix_zero_aux_records-v1-1-23b95e8d5df3@arm.com Signed-off-by: Sasha Levin commit 06a994ad7bbd13714cd45df582389f751531e60c Author: Ivy Lopez Date: Tue Aug 25 13:03:13 2026 -0600 scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() [ Upstream commit e0d26fe176a8db6ccad4ab38c5bab29391c1946b ] dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221294 Suggested-by: Johannes Thumshirn Fixes: 728bbc6cbff7 ("scsi: mpt3sas: Affinity high iops queues IRQs to local node") Signed-off-by: Ivy Lopez Reviewed-by: John Garry Link: https://patch.msgid.link/20260825190313.24013-1-skunkolee@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 862c8eb6947689c44fe11353755576a3672563a5 Author: Eric Dumazet Date: Mon Aug 31 19:46:26 2026 +0000 bonding: alb: fix uninitialized transport header access in alb_determine_nd() [ Upstream commit 70f3995830d3f1e79faa14eb0605914f778feca9 ] alb_determine_nd() uses icmp6_hdr(skb) to inspect ICMPv6 headers. However, in xmit paths (e.g. packets sent via AF_PACKET / raw sockets or forwarded packets), skb->transport_header is not guaranteed to be initialized. While pskb_network_may_pull() ensures the packet data is linear starting from the network header, it does not set or adjust the transport header offset. Dereferencing icmp6_hdr(skb) can therefore access out-of-bounds memory. Fetch the icmp6hdr directly after ipv6hdr following pskb_network_may_pull(), and reload ipv6hdr in case pskb_may_pull() reallocated skb->head. Also remove the unused bond argument from alb_determine_nd(). Fixes: 0da8aa00bfcf ("net: bonding: Add support for IPV6 ns/na to balance-alb/balance-tlb mode") Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260831194626.119371-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 49179f13c04735c55fd0f43b03696c015b067137 Author: Guanghui Yang <3497809730@qq.com> Date: Mon Aug 10 20:16:05 2026 +0800 btrfs: restore active device pointers after failed sprout [ Upstream commit e0b54613aabeb8e9da597f23b90c6a03d0981986 ] btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device. Fixes: b7cb29e666fe ("btrfs: update latest_dev when we create a sprout device") 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 63bfa52eb3289517aa82cb90e1189385873aae21 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 28869353ab83a7fa08fe5fe7b12c84b0257a63b1 Author: wangdicheng Date: Mon Aug 24 14:35:07 2026 +0800 ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() [ Upstream commit 1b67e0d3b9691d7b6b74e18960ddd2be24f9dc9d ] acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree. Fixes: 7610174a5bfe ("ASoC: amd: add acp6x pdm platform driver") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260824063507.483784-2-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 23dc0f81ea2a447caa289a836e5d6d4a91e8f2b7 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 f2451e18826eb6a33ea51419f39bdd2eb99fa1ea 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 09e3c9b32434600a6992e762bf0d6837f5902134 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 9cfbe2c381ab6d00a08e7a5b6028865adfb4e1bc 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 6188cf0c989dea60f2efe800eaebb7d0bd16e2b2 Author: Tung Nguyen Date: Thu Aug 27 18:13:46 2026 +0700 tipc: fix NULL deref in tipc_named_node_up() on empty publication list [ Upstream commit b3b76e9f4f2476f1135b2ba7743a821db4a0df4b ] User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid. Fixes: a5e7ac5ce134 ("tipc: fix regression bug where node events are not being generated") Reported-by: Xiang Mei Tested-by: Weiming Shi Signed-off-by: Tung Nguyen Link: https://patch.msgid.link/20260827111418.164957-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65f1c423f54da703b9e370b05f2f350886a4f9fe Author: Eric Dumazet Date: Fri Aug 28 10:37:31 2026 +0000 ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit [ Upstream commit 97cc84dad1d7f68a36b71b69b361d88482707673 ] Shuangpeng Bai reported a KASAN slab-use-after-free in ip6gre_tunnel_xmit(). The precise KASAN bug was caused by ip6_tnl_xmit() consuming the skb during headroom expansion and returning an error, while ip6gre_tunnel_xmit() still held the stale pointer and called skb_tunnel_info_txcheck(skb) at tx_err. That specific bug was fixed by commit 87f21b59ddc6 ("ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()"). However, calling skb_tunnel_info_txcheck(skb) at the tx_err label after the transmission attempt remains problematic: Downstream helpers like ip6_tnl_xmit() call skb_scrub_packet(), which drops the skb's metadata_dst before transmission. If an error occurs later during transmit, inspecting skb at tx_err sees a scrubbed dst and misclassifies tx_errors vs tx_dropped. Commit e5f7e211b6aa ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels") already handled this correctly in ip6erspan_tunnel_xmit() by checking and caching tun_info before transmit. Align ip6gre_tunnel_xmit() with ip6erspan_tunnel_xmit() by caching tun_info before xmit and checking it at tx_err. Fixes: e5f7e211b6aa ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels") Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/netdev/20260819062224.3197349-1-shuangpeng.kernel@gmail.com/ Cc: Davide Caratti Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828103731.1951815-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b2c86d4291be4c25bafc47289b79ace2f573bca5 Author: Eric Dumazet Date: Tue Nov 15 08:53:57 2022 +0000 ipv6: tunnels: use DEV_STATS_INC() [ Upstream commit 2fad1ba354d4a82b1b635a78f25d9682d4febb5e ] Most of code paths in tunnels are lockless (eg NETIF_F_LLTX in tx). Adopt SMP safe DEV_STATS_{INC|ADD}() to update dev->stats fields. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: 97cc84dad1d7 ("ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit") Signed-off-by: Sasha Levin commit 696b80efadea1ad5ba3893602db987d44a777474 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 f4ee13ed7f7b22dcd8287fcf477ae37bd84567da Author: Jamal Hadi Salim Date: Tue Aug 25 04:10:51 2026 -0400 net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted [ Upstream commit d7e7e98d23f42a92d9ab7e36302bd96bd9b33b5f ] gen_new_kid() falls back to returning max (htid | 0xFFF) when both idr_alloc_u32() ranges are full, instead of reporting an error. u32_change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space. The handle was never reserved in ht->handle_idr, so every later error path that does idr_remove(&ht->handle_idr, handle) removes the reservation of a different, live knode, which is then reused — one failed add compounds into further duplicates. The 4095 limit is per (table, bucket) — ht->handle_idr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 256*4095 knodes. The sibling helper gen_new_htid() has the same silent in-band failure: it returns 0 when the tp_c handle pool (1..0x7FF) is full, and u32_init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32_lookup_ht(), allowing cross-tcf_proto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has. Return an error so u32_change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32_init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAP_NET_ADMIN). - For gen_new_htid: create 2047 u32 proto entries on the same block to fill the tp_c handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables. Fixes: 7801db8aec95 ("net_sched: avoid generating same handle for u32 filters") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081052.133898-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7b09caa89ddeafd83c4cd33542c47c2a836ff68e 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 590d22e53774f719e5403b1d4c6e39d67f5ce654 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 4781e7d11abd4d4aa855190541abb8a0d6518c28 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 10929680d2c2576727d171cc219237a28a8318c6 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 a3fd03f14c258bcf533277f41d57a877fd59d447 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 41af2a82413881f26fe1b81f25a0c80023361c7b 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 aab17938998b29e75c3324763411aef3e300fc67 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 674aabf554bdaffcf25f145bf32c8b4f510f7916 Author: Namjae Jeon Date: Tue Aug 25 09:32:23 2026 +0900 ksmbd: rate limit unmapped SID errors [ Upstream commit feca5e70fc963b088377b20879e8cd8237c2fd7d ] A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9857a75714bb5df4781e4d8b1a1753b1e17bf07a Author: Yilin Zhang Date: Mon Aug 31 12:55:06 2026 +0800 ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF [ Upstream commit 9b110a9dcecc59516c77cb3c0caf1f492f75df2d ] snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request. Reported-by: Kimi Security Team Fixes: 92ee3c60ec9f ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls") Signed-off-by: Yilin Zhang Link: https://patch.msgid.link/20260831045506.889070-1-yilinzhang@moonshot.ai Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 26082113a66beedc98f4940a04003e5442a6a7c7 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 afc3ea51e479289a23c642cc8bade67b94225ed9 Author: Tzung-Bi Shih Date: Thu Aug 27 04:46:59 2026 +0000 watchdog: msc313e: Fix NULL pointer dereference in PM callbacks [ Upstream commit e3eceb76515910746e6268c4e4ac1c07516ebd7b ] msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe(). Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260827044700.554333-2-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 977a1338e774509a6efab2d2ac3ec0b1e90f2b63 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 ef401083d004eca2b233bb9f0d969036cb9a0a9d Author: Xuanqiang Luo Date: Fri Aug 28 09:29:18 2026 +0800 raw: annotate disconnect-side IPv4 match writers [ Upstream commit ac08d183dac0441e41f77bbad50798fe609d90f1 ] raw_v4_match() reads inet_daddr, inet_rcv_saddr and sk_bound_dev_if locklessly under RCU. Bind and connect writers are annotated, but __udp_disconnect() still clears the same fields using plain stores. Commit 18f116931f52e ("raw: annotate lockless match fields in raw_v4_match()") added the lockless readers and annotated the raw bind and datagram connect writers. Its v4 revision intentionally left the shared disconnect-side IPv4 writers for follow-up cleanup. Complete that follow-up by using WRITE_ONCE() for the disconnect-side stores, including the inet_rcv_saddr reset in inet_reset_saddr(), to pair with the lockless raw socket matcher. Fixes: 0daf07e52709 ("raw: convert raw sockets to RCU") Link: https://lore.kernel.org/netdev/20260716142958.3064224-1-runyu.xiao@seu.edu.cn/ Suggested-by: Runyu Xiao Signed-off-by: Jackie Liu Signed-off-by: Xuanqiang Luo Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828012918.1461-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fbc6a778d5fce7628821236972596acb18e1065 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 2044508b7bb5508a15164e5d4beb3a10b62702c4 Author: Andy Shevchenko Date: Tue Aug 25 10:30:43 2026 +0200 smb: client: transport: Fix debug printing in __release_mid() [ Upstream commit d83a21bb26015bfdd79b0440fe816b271b8bbab3 ] Long time ago during upgrading printk():s to the respective pr_() calls one misconversion happened and nobody has noticed that. So, previously printk(KERN_DEBUG) + printk() worked as one long debug print since the trailing '\n' is only present in the followup printk() format string. The culprit change missed that and split the message to two on the different levels. Restore the original behaviour to make users be less confused in the most likely never happen cases of partially getting that message. Fixes: 0b456f04bcdf ("cifs: convert printk(LEVEL...) to pr_") Signed-off-by: Andy Shevchenko Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit ba0aea71ba05975ed9f29e234020e2870d0546d7 Author: Huiwen He Date: Fri Aug 28 15:19:31 2026 +0800 smb/client: mark file sparse before emulating insert range [ Upstream commit cd03ce4950d80147ac8f20bc03c42b75b0352407 ] The SMB client emulates FALLOC_FL_INSERT_RANGE with SET_EOF, COPYCHUNK and SET_ZERO_DATA. SET_ZERO_DATA creates a hole only when the file is sparse. On a non-sparse file, it clears the inserted range but leaves its blocks allocated, causing the extent count check in xfstests generic/064 to fail. Fix this by marking the file sparse before modifying it. This patch produces the expected sparse extents in xfstests generic/064 only when the server-reported block size is compatible with the server's deallocation granularity. For ksmbd, the reported block size follows the backing filesystem, and the test passes. For Samba, the test passes with a block size matching the backend granularity, for example, 4 KiB on Btrfs, but not with the default 1 KiB value. For Windows Server 2022, 4 KiB inserts do not generate holes, while aligned inserts of 64 KiB or larger do. Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 60a9aaac07f6470b252c4de40e7d8a6e25004093 Author: Milan P. Gandhi Date: Wed Aug 12 16:03:44 2026 +0530 scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add() [ Upstream commit 419d129f970aaa6567dbac366b0c93784bf9ec97 ] mpi3mr_get_tgtdev_by_addr() increments the target device kref when it returns a device. If a subsequent error triggers a goto out_fail after the tgtdev reference is acquired, the reference is never released because the out_fail path does not call mpi3mr_tgtdev_put(). This prevents the target device structure from ever being freed. Add a tgtdev put in the out_fail path, guarded by a NULL check since tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL. Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL") Signed-off-by: Milan P. Gandhi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260812103344.174247-3-mgandhi@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 7e3489b5950e7668355762968a7c7f75fe9bc80d Author: Milan P. Gandhi Date: Wed Aug 12 16:03:43 2026 +0530 scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add() [ Upstream commit dba9e2181ca5e875f98b8b9b4535cdaab87dcb0d ] sas_port_alloc_num() can return NULL on memory allocation failure. The return value is passed directly to sas_port_add() without a NULL check, which causes a NULL pointer dereference. Additionally, if sas_port_add() fails, the allocated port is not freed before jumping to out_fail, leaking the sas_port structure. Call sas_port_free() to properly release it. Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL") Signed-off-by: Milan P. Gandhi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260812103344.174247-2-mgandhi@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 755d70ca845fd9b87c7b338ae6ae832b08cd0005 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 550d5be6b88c7b4c3cfaee914fc2985783a9a801 Author: Victor Nogueira Date: Mon Aug 24 12:39:02 2026 -0300 net/sched: act_api: fix skb sizing and action leak on reoffload delete [ Upstream commit 251367a0a3319fa565daf7468b0afd933b1f5ab1 ] tcf_reoffload_del_notify_msg() sizes the RTM_DELACTION skb with tcf_action_fill_size(action) alone. Unlike every other notification path it never wraps that in tcf_action_full_attrs_size(), so the nlmsg_put() header, struct tcamsg and the TCA_ACT_TAB nest that tca_get_fill() emits - 24 bytes on x86_64 - are not budgeted. As long as the single action stays well under NLMSG_GOODSIZE the floor in alloc_skb() hides this, but once its fill size crosses NLMSG_GOODSIZE the allocation is exactly 24 bytes short and tca_get_fill() runs out of tailroom. That is now easy to reach for an offloadable act_pedit with a large tcfp_nkeys, which commit 8e2efb3f45a5 ("net/sched: add get_fill_size callbacks for actions missing them") started accounting for properly. When that happens tcf_reoffload_del_notify() returns early, before tcf_idr_release_unsafe(), and tcf_action_reoffload_cb() discards the return value: if (tc_act_skip_sw(p->tcfa_flags) && !tc_act_in_hw(p)) tcf_reoffload_del_notify(net, p); The action has just lost its last hardware instance and is skip_sw, so it is left installed while processing no packets, and with no notification to tell userspace about it. An -ENOBUFS from alloc_skb() gets the same treatment. Fix this by budgeting the message header the way the add and delete paths do, and release the action even when the notification cannot be built - dropping the notification is strictly better than leaking a dead action, and there is no caller left to report the error to. Fixes: 13926d19a11e ("flow_offload: add reoffload process to update hw_count") 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 Reviewed-by: Pedro Tammela Link: https://patch.msgid.link/20260824153903.4143642-4-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c32c74801fbfe32e931b29da74c135341ca7d1f8 Author: Pedro Tammela Date: Fri Dec 8 16:28:45 2023 -0300 net/sched: act_api: conditional notification of events [ Upstream commit 8d4390f51920c1edb2d09d44d918c7940ac51e54 ] As of today tc-action events are unconditionally built and sent to RTNLGRP_TC. As with the introduction of rtnl_notify_needed we can check before-hand if they are really needed. Signed-off-by: Pedro Tammela Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20231208192847.714940-6-pctammela@mojatatu.com Signed-off-by: Jakub Kicinski Stable-dep-of: 251367a0a331 ("net/sched: act_api: fix skb sizing and action leak on reoffload delete") Signed-off-by: Sasha Levin commit 41c56b0d35edd8864a7237adc46788270cd9e958 Author: Pedro Tammela Date: Fri Dec 8 16:28:44 2023 -0300 net/sched: act_api: don't open code max() [ Upstream commit c73724bfde0932cb0cafff2855e8ce81e12fd594 ] Use max() in a couple of places that are open coding it with the ternary operator. Signed-off-by: Pedro Tammela Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20231208192847.714940-5-pctammela@mojatatu.com Signed-off-by: Jakub Kicinski Stable-dep-of: 251367a0a331 ("net/sched: act_api: fix skb sizing and action leak on reoffload delete") Signed-off-by: Sasha Levin commit 910e837fb00340896c6a91c2142cca125c9fd823 Author: Pedro Tammela Date: Fri Dec 8 16:28:43 2023 -0300 rtnl: add helper to send if skb is not null [ Upstream commit ddb6b284bdc32b6e218b3d90b5a745ea26620812 ] This is a convenience helper for routines handling conditional rtnl events, that is code that might send a notification depending on rtnl_has_listeners/rtnl_notify_needed. Instead of: if (skb) rtnetlink_send(...) Use: rtnetlink_maybe_send(...) Reviewed-by: Jiri Pirko Reviewed-by: Simon Horman Signed-off-by: Pedro Tammela Link: https://lore.kernel.org/r/20231208192847.714940-4-pctammela@mojatatu.com Signed-off-by: Jakub Kicinski Stable-dep-of: 251367a0a331 ("net/sched: act_api: fix skb sizing and action leak on reoffload delete") Signed-off-by: Sasha Levin commit e9720428650351b26414f00b32624f98179e0564 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 794987d7e51330232813fb85af7b731eee186a0b 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 ec6d4612d1c170e1cef1fe55526471da1e81e777 Author: Eric Dumazet Date: Tue Aug 25 08:45:51 2026 +0000 net: icmp: avoid invalid transport header access in icmp_send tracepoint [ Upstream commit 7fcc2fe39fed1cb98a7374a113ff3800e8f9af80 ] syzbot reported a WARNING triggered by DEBUG_NET_WARN_ON_ONCE(): WARNING: at skb_transport_header include/linux/skbuff.h:3087 [inline] WARNING: at udp_hdr include/linux/udp.h:23 [inline] WARNING: at do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline] WARNING: at trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11 Call trace: skb_transport_header include/linux/skbuff.h:3087 [inline] udp_hdr include/linux/udp.h:23 [inline] do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline] trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11 __traceiter_icmp_send include/trace/events/icmp.h:11 [inline] __do_trace_icmp_send include/trace/events/icmp.h:11 [inline] trace_icmp_send+0x320/0x49c include/trace/events/icmp.h:11 __icmp_send+0xcfc/0x11d8 net/ipv4/icmp.c:1013 ipv4_send_dest_unreach net/ipv4/route.c:1280 [inline] ipv4_link_failure+0x57c/0x8dc net/ipv4/route.c:1287 dst_link_failure include/net/dst.h:438 [inline] vti_tunnel_xmit+0xe40/0x17a4 net/ipv4/ip_vti.c:307 TP_fast_assign() unconditionally calls udp_hdr(skb) before checking whether the packet is UDP. Furthermore, __icmp_send() can be invoked from paths (e.g., link failures, ARP errors, forwarding, AF_PACKET) where skb->transport_header was never initialized (~0U). Under CONFIG_DEBUG_NET=y, calling skb_transport_header(skb) triggers DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)). Fix this by: 1. Only parsing transport info when iph->protocol == IPPROTO_UDP. 2. Using skb_header_pointer() at skb_network_offset(skb) + (iph->ihl << 2) to safely fetch the UDP header without assuming transport_header is set. Fixes: db3efdcf70c7 ("net/ipv4: add tracepoint for icmp_send") Reported-by: syzbot+6d2762674103618994b0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a8d5538.91706f20.ef82.0009.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Peilin He Cc: xu xin Cc: Steven Rostedt Reviewed-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260825084551.1562967-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e964b084fb297b9b6ce8634008cdb61b269ba1c 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 c2459519b39587c9c27d6b8a8cf516fee10fce66 Author: Xixin Liu Date: Wed Aug 19 14:30:00 2026 +0800 nvme-rdma: fix -EIO cleanup order in queue_rq [ Upstream commit d61828199c6cb4b76d48403c77023cd4bb9d09fc ] On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path. Fixes: 62eca39722fd ("nvme-rdma: handle nvme_rdma_post_send failures better") Reviewed-by: Christoph Hellwig Signed-off-by: Xixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5eda6cda0031ba17559d56882353be39e568ec09 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 656e2fe98ac452db4e5b8147d1f33b8c35b4ec4b 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 0c5c5d2b75a9918d09721ecf30c8a6dc2e406ed7 Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:32 2026 +0800 EDAC/igen6: Fix channel address decode for non-hash mode [ Upstream commit 7b348d0d401d478f1923ba20a34a61681d1f7971 ] In non-hash mode, decode_channel_addr() and channel index extraction used a hardcoded interleave bit position 6 instead of the actual intlv_bit parameter, causing incorrect channel address decoding. Fix this by using intlv_bit consistently in both hash and non-hash modes. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-5-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit be21bd40450727fd350beebf8665178f0ee7d23b Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:31 2026 +0800 EDAC/igen6: Fix channel selection hash [ Upstream commit 540b79536f3a89a66c5b6c490110298d43025618 ] In channel selection hash mode, the hardware decoding logic always includes the channel interleave bit in XOR operations. However, the hash mask may or may not include this channel interleave bit. When the mask does include this bit, the current igen6_edac code performs XOR on the interleave bit twice, effectively ignoring it - which is incorrect. Fix this issue by ensuring the hash mask always includes the interleave bit, so XOR is performed on the interleave bit exactly once. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-4-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit a8a12c7ab9bfd27bc1c55bd2c1553768d3d8609f Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:30 2026 +0800 EDAC/igen6: Fix interleave boundary condition [ Upstream commit f4008169bd320eedb9ddf2b39eeb21370ddac278 ] The address translation logic splits the memory space into interleaved and non-interleaved regions using a boundary at 2 * s_size. The current check uses '>' and incorrectly classifies the boundary address (2 * s_size) as part of the interleaved region. This leads to incorrect channel/sub-channel selection at the region boundary. Fix the classification by using '>=' so that the boundary address is handled in the non-interleaved region, matching the hardware layout. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit a70e30df0f2498e2208ae04d5cb8b2bc410fe72a Author: Russell King (Oracle) Date: Fri Dec 5 12:17:00 2025 +0000 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: Sasha Levin commit 3bcfa8d173b7b350b992cf5fd79f4ecd329f8943 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 6f5dfdca6cfb93946a906a23d66fb51dc7955669 Author: Sasha Levin Date: Mon Sep 14 20:21:35 2026 -0400 Revert "Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU" This reverts commit 128aa24b355690e76babcaa463c29618b20a4ac9. Signed-off-by: Sasha Levin commit 3a50184f46482f63c524fa266a292d95b811ea1c Author: Sasha Levin Date: Mon Sep 14 20:21:35 2026 -0400 Revert "Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU" This reverts commit 566d0ed699a17e4a52e5ba18a73a548c343fa748. Signed-off-by: Sasha Levin commit 65edd8b3a88278c9f8e5c7d8c15d4f296ce35078 Author: SJ Park Date: Fri Sep 11 06:49:04 2026 -0700 mm/damon/core: avoid infinite kdamond_merge_regions() internal loop commit 123e4619ab6c8ab1c4cb1d7a58311a2af13929cd upstream. Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-1-sj@kernel.org Link: https://lore.kernel.org/20260715031002.108504-2-sj@kernel.org Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [1] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit 2b6c2842692d08e7acaf32d1eb47f95def35f3fe Author: Kuniyuki Iwashima Date: Tue Aug 4 00:21:54 2026 +0000 af_unix: Unlink scc_entry in unix_del_edge(). [ Upstream commit 594d905195024b228c962627ae5ae7c17bd582a4 ] Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge(). Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") Reported-by: Kyle Zeng Signed-off-by: Kuniyuki Iwashima Reviewed-by: Kyle Zeng Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm."). Link: https://patch.msgid.link/20260804002155.2233594-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7bde6f181fa307d2cc1ec2b0313ac8e9811c8232 Author: Namjae Jeon Date: Mon Jul 20 10:32:01 2026 +0900 ksmbd: use memcmp() to compare ClientGUIDs [ Upstream commit e8bb506e6ef749ac0336f3e579d8d02396b7d832 ] ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Samu Suggested-by: Samu Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 91797708f99e4a910ab019760069c0a7e00a6fc0 Author: HyeongJun An Date: Tue Jun 9 21:43:14 2026 +0900 ASoC: meson: aiu: Validate written enum values [ Upstream commit d65adf85477247be04ac86886f8edfaa047b5d4a ] The AIU HDMI and internal codec mux put callbacks use the written enum value with snd_soc_enum_item_to_val() before checking whether the value is valid for the enumeration. Reject out-of-range values before converting the enum item, matching the validation already done by the G12A HDMI and internal codec mux controls. Fixes: b82b734c0e9a ("ASoC: meson: aiu: add hdmi codec control support") Fixes: 65816025d461 ("ASoC: meson: aiu: add internal dac codec control support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260609124317.38046-3-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8bdb20b8a581495062b5879f4e9d435da648b3b0 Author: Kuniyuki Iwashima Date: Wed Jun 10 06:17:18 2026 +0000 ipv4: fib: Don't dump dying fib_info in fib_leaf_notify(). [ Upstream commit 06b693d2eb6651a63ad85bad8673de3b7d4edd6d ] syzbot reported use-after-free in nsim_fib4_prepare_event(). [0] The problem is that the following functions call fib_info_hold() / refcount_inc() while dumping fib_info under RCU, which is unsafe. * mlxsw_sp_router_fib4_event() * rocker_router_fib_event() * nsim_fib4_prepare_event() refcount_inc_not_zero() must be used, but it would be too late there. Let's guarantee the lifetime of fib_info in fib_leaf_notify(). Note that IPv6 does not need the corresponding change since fib6_table_dump() holds fib6_table.tb6_lock. [0]: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420 Modules linked in: CPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Workqueue: netns cleanup_net RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25 Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a <67> 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f RSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293 RAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0 RBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000 R13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000 FS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] fib_info_hold include/net/ip_fib.h:629 [inline] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25 call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline] fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline] fib_table_notify net/ipv4/fib_trie.c:2194 [inline] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217 fib_net_dump net/core/fib_notifier.c:70 [inline] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c:475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558 ops_pre_exit_list net/core/net_namespace.c:161 [inline] ops_undo_list+0x187/0x940 net/core/net_namespace.c:234 cleanup_net+0x56e/0x800 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: 0ae3eb7b4611 ("netdevsim: fib: Perform the route programming in a non-atomic context") Fixes: c3852ef7f2f8 ("ipv4: fib: Replay events when registering FIB notifier") Reported-by: syzbot+cb2aa2390ac024e25f5c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a290011.39669fcc.33b062.00b1.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260610061744.2030996-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8e6a839c0e7ca1da752faaab51e2eafb17483a4 Author: Xin Long Date: Sat Jun 20 11:48:54 2026 -0400 sctp: fix err_chunk memory leaks in INIT handling [ Upstream commit 9f58a0a4d6c2ed5d341bba64f058f15d1b0c36f2 ] When sctp_verify_init() encounters unrecognized parameters, it allocates an err_chunk to report them. However, this chunk is leaked in several code paths: 1. In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after sctp_verify_init() has populated err_chunk, the function returns immediately without freeing it. 2. In sctp_sf_do_unexpected_init(), the same leak occurs on the security_sctp_assoc_request() failure path. 3. In sctp_sf_do_unexpected_init(), on the success path after copying unrecognized parameters to the INIT-ACK, the function returns without freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees it. Fix all three leaks by adding sctp_chunk_free(err_chunk) calls before returning in the error paths and on the success path in sctp_sf_do_unexpected_init(). Fixes: c081d53f97a1 ("security: pass asoc to sctp_assoc_request and sctp_sk_clone") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Signed-off-by: Xin Long Reviewed-by: Simon Horman Link: https://patch.msgid.link/0656704f1b0158287c98aec09ba36c83e4a537ab.1781970534.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b767a5d7c6cb595f9feb00b5af96191a59efca26 Author: Nuoqi Gui Date: Tue Jun 23 18:43:38 2026 +0800 bpf: Mask pseudo pointer values in verifier logs [ Upstream commit 72a85e9464a5332fb2cd7efd26d9295275ceda2d ] print_bpf_insn() masks ldimm64 immediates for pointer-bearing pseudo sources when pointer leaks are not allowed, but the mask only covers BPF_PSEUDO_MAP_FD and BPF_PSEUDO_MAP_VALUE. BPF_PSEUDO_MAP_IDX, BPF_PSEUDO_MAP_IDX_VALUE, and BPF_PSEUDO_BTF_ID can also be resolved to kernel pointer values before the verifier log prints the instruction. Include them in the existing pointer classification so the log prints 0x0 instead of the rewritten address. Fixes: 4976b718c355 ("bpf: Introduce pseudo_btf_id") Fixes: 387544bfa291 ("bpf: Introduce fd_idx") Signed-off-by: Nuoqi Gui Link: https://lore.kernel.org/r/20260623-f01-13-pseudo-btf-id-cap-bpf-v2-1-a190ebb8f3e2@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Acked-by: Eduard Zingerman Signed-off-by: Sasha Levin commit d2df29dc9abda2fc10ff522eac0969f5b77b3637 Author: Pauli Virtanen Date: Wed Jul 1 18:46:38 2026 +0300 Bluetooth: ISO: fix malformed ISO_END/CONT handling [ Upstream commit e054c1a6ae7310d2815778fddb87da616e11c255 ] Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. If controller sends too short ISO_END we accept it. Fix by marking unfinished ISO_START via conn->rx_skb != NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets. Fixes: 84c24fb151fc ("Bluetooth: ISO: drop ISO_END frames received without prior ISO_START") Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 84674dd1d3192ecb050827d3148642609c0c9dbb Author: Pauli Virtanen Date: Fri Jul 10 11:23:42 2026 +0300 Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds [ Upstream commit da55f570191d5d72f10c607a7043b947eb05ea46 ] Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race. Fixes: 7b445e220db9 ("Bluetooth: MGMT: Fix holding hci_conn reference while command is queued") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9fd4f92671146b068809b6c34b50346cb30cf8f7 Author: Cen Zhang (Microsoft) Date: Mon Jul 20 17:41:03 2026 -0400 tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() [ Upstream commit 47f42ff521b4eeb46e82f9a46a4783a99f7570d7 ] In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe. Fixes: e9f8b10101c6 ("tipc: refactor function tipc_sk_recvmsg()") Fixes: ec8a09fbbeff ("tipc: refactor function tipc_sk_recv_stream()") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260720214103.47732-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d427b152b663cb2b19fcd449d792e17edbe4a938 Author: Yehyeong Lee Date: Wed Jul 22 21:28:17 2026 +0900 net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD [ Upstream commit 5e9c8baee0329fbefe7c67aea945e2a07f15e98b ] net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Suggested-by: Eric Dumazet Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260722122817.5548-1-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1275a4769c126405c6c63b6372daff120ac679a6 Author: Eric Dumazet Date: Wed Jul 22 14:17:42 2026 +0000 drop_monitor: fix size calculations for 64-bit attributes [ Upstream commit 7089f7ab99c89f443c92d8fcc585e63f2727f0b3 ] net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260722141743.3266924-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd8472526a04f2185afd792b8041a912a7d75d85 Author: Eric Dumazet Date: Wed Jul 22 14:17:43 2026 +0000 drop_monitor: perform u64_stats updates under IRQ-disabled section [ Upstream commit fd098a23bf8fda7eae48db9b06e7c34fc4d228fa ] In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update. Fixes: e9feb58020f9 ("drop_monitor: Expose tail drop counter") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260722141743.3266924-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c29affd44e6769e3073235d4b471d9b501fa8166 Author: Zhiling Zou Date: Wed Jul 15 09:50:11 2026 +0800 sctp: close UDP tunnel sockets during netns teardown [ Upstream commit ffb2bd7ade36ec4da32c46a6eddbf4515316d08c ] proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/b9f1f02b0780ad6a719e2413f5f0bb8eb7702d94.1782585631.git.roxy520tt%40gmail.com Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/6dab75f22855cb219e2e30a5497cab03b970ab91.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a2d9fe0e87c71baa0aaa1cfc1361892fcd1ece0 Author: Namjae Jeon Date: Sat Jul 4 11:07:51 2026 +0900 ksmbd: validate ACE size against SID sub-authorities [ Upstream commit 5152c6d49e3fd4e9f2e857c57527aead752f1f87 ] set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths. Reported-by: LocalHost Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ff035780adb0f49dc2c7ada26b4697849a68bec8 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 4df1eb56b96b5b911abf548d4fb1aecbe0c5146d Author: Laxman Acharya Padhya Date: Sun Aug 16 23:33:40 2026 +0545 wifi: mt76: mt7921: skip unknown CLC firmware records [ Upstream commit 1a296bfd3e775e515233f746218824fc7dd5ff16 ] Treat an out-of-range CLC index as newer firmware rather than a malformed image. linux-firmware 20260810 ships MT7922 records with idx 3, and rejecting them made mt7921e fail to probe. Keep the record-length checks, and report those as errors so a truncated table is visible instead of a silent retry loop. Fixes: 9417c5818a01 ("wifi: mt76: mt7921: validate CLC firmware records") Reported-by: Mikhail Gavrilov Signed-off-by: Laxman Acharya Padhya Reviewed-by: Junjie Cao Tested-by: Mikhail Gavrilov Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 46673662402884ca55a869e4ebe956e08e8b6b05 Author: Laxman Acharya Padhya Date: Tue Jul 21 10:17:40 2026 +0000 wifi: mt76: mt7921: validate CLC firmware records [ Upstream commit 9417c5818a0146980c2608fda94c908e604eb033 ] The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying. Fixes: 23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support") Signed-off-by: Laxman Acharya Padhya Link: https://patch.msgid.link/CAMyXUJmh=WfwC4_KHupNxYR5e2Gy5QhBDL5TSG6XEW-XLa+X4Q@mail.gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3c35c4ddaf6856fac464f1f4f9fd399a99754ea0 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 9befcbd7e6a98f5fa5b959c4a125d1e7d103218e Author: Christophe JAILLET Date: Sat Oct 21 16:42:41 2023 +0200 tracing/histograms: Simplify last_cmd_set() [ Upstream commit 545db7e21e64766e6b7cb987fbfd3e79419726ce ] Turn a kzalloc()+strcpy()+strncat() into an equivalent and less verbose kasprintf(). Link: https://lore.kernel.org/linux-trace-kernel/30b6fb04dadc10a03cc1ad08f5d8a93ef623a167.1697899346.git.christophe.jaillet@wanadoo.fr Cc: Masami Hiramatsu Signed-off-by: Christophe JAILLET Reviewed-by: Mukesh ojha Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit f8200bb4994e65a2e5c5b314789eeae39078619d Author: Gil Portnoy Date: Sun Jul 12 00:00:00 2026 +0000 ksmbd: remove stale channels from all sessions on teardown [ Upstream commit b10665730fbf6b5e45fe422badcbbc3f0df96ef5 ] ksmbd_sessions_deregister() removes a connection's channels from other sessions' channel lists only while conn->binding is still set: if (conn->binding) { hash_for_each_safe(sessions_table, ...) ksmbd_chann_del(conn, sess); } conn->binding is a transient flag: it is cleared once a binding SESSION_SETUP completes, and also by a subsequent non-binding SESSION_SETUP on the same connection (a reauthentication on a bound channel, or a new SessionId==0 setup). A connection that has bound a channel into another session's ksmbd_chann_list and then clears conn->binding leaves that channel behind when it disconnects: the channel, whose chann->conn points at the now freed struct ksmbd_conn, stays on the owner session's list. When the owning connection later tears down, the second loop dereferences the stale channel: xa_for_each(&sess->ksmbd_chann_list, chann_id, chann) if (chann->conn != conn) ksmbd_conn_set_exiting(chann->conn); /* freed */ which is a use-after-free write into the freed ksmbd_conn (the same stale channel is also walked by show_proc_session() through /proc). The session is leaked as well, because its channel list never empties. Remove the conn->binding gate so a connection always removes its channels from every session on teardown. Fixes: faf8578c77f3 ("ksmbd: find bound sessions during reauthentication") Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit da478182045d87747f0423cea4183bd7e0234a87 Author: Genevieve Chan Date: Mon Jul 6 13:55:41 2026 +0800 firmware: stratix10-svc: fix FCS SMC call kernel-doc [ Upstream commit 9b9a6e31bdd1ff20c3ffdab87431672d8bfc2a07 ] Correct kernel-doc errors for two FCS SMC calls: INTEL_SIP_SMC_FCS_SEND_CERTIFICATE: - Describe as async to match STD_CALL_VAL usage - Replace INTEL_SIP_SMC_FCS_REJECTED with INTEL_SIP_SMC_REJECTED INTEL_SIP_SMC_FCS_GET_PROVISION_DATA: - Replace FCS-specific status macros with standard status macros (INTEL_SIP_SMC_STATUS_ERROR and INTEL_SIP_SMC_STATUS_REJECTED) - Restore return register documentation for a1 (mailbox error), a2 (physical address), and a3 (structure size) Fixes: 4a4709d470e6 ("firmware: stratix10-svc: add new FCS commands") Fixes: 4b0a32016347 ("firmware: stratix10-svc: change get provision data to async SMC call") Cc: stable@vger.kernel.org # 6.0+ Signed-off-by: Genevieve Chan Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 5570d6c8b320dbcc602617ee08c27ce752fed65a Author: Florian Westphal Date: Mon Aug 3 10:43:27 2026 +0200 netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state [ Upstream commit 33d1469b0124cc0baaea7a2032123b77a81e0940 ] sashiko reports: "nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock()." Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data. Link: https://sashiko.dev/#/patchset/20260731151806.849724-1-pablo%40netfilter.org Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3bc7af4cefac1c583f0607f6183a67012436aad9 Author: Zizhi Wo Date: Thu Jul 23 12:12:38 2026 +0800 scsi: core: Do not block on tag allocation in scsi_eh_lock_door() [ Upstream commit 732cb6bb37fd26863d5786522fb1997e7f5865b4 ] scsi_eh_lock_door() is called from scsi_restart_operations() while the host is still in the SHOST_RECOVERY state, i.e. before the host is switched back to SHOST_RUNNING and scsi_run_host_queues() restarts the queues. It allocates a request via scsi_alloc_request() with no flags, so blk_mq_get_tag() may block waiting for a free sched tag when all tags are already in use. Those tags can be held by commands that were just requeued by scsi_eh_flush_done_q() during error handling. Such commands cannot be dispatched until the host leaves SHOST_RECOVERY and scsi_run_host_queues() is called - which only happens *after* scsi_eh_lock_door() returns. This forms a circular dependency: - scsi_eh_lock_door(), running in the SCSI error handler thread, waits for a sched tag held by a requeued command; - the requeued command cannot complete and release its sched tag until the error handler thread leaves scsi_restart_operations() and restart the queues. For devices with a single driver tag (e.g. USB storage) it is a guaranteed deadlock and I/O that can never be submitted. This problem has also been reproduced in our environment. Locking the door is a best-effort operation, and scsi_eh_lock_door() already returns silently when the request allocation fails. Pass BLK_MQ_REQ_NOWAIT to scsi_alloc_request() so the allocation fails instead of blocking when no tag is available. This breaks the circular dependency and allows the error handler to finish restarting the queues, after which the pending commands are dispatched normally. Signed-off-by: Zizhi Wo Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260723041238.1584632-1-wozizhi@huaweicloud.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 7115a76e1d3d72ac542c5c2ce412ce4f545c44dc 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 bcee77e60cecaf44ab5ad9c99e874e6c061afeff Author: Jisheng Zhang Date: Mon Aug 3 21:59:25 2026 +0800 spi: dw: fix wrong RX_SAMPLE_DLY setting after resume [ Upstream commit 133c71b2c0bc976a4751f9e05ef7cdea67f964e5 ] On platforms which need a non-zero rx sample delay, the RX_SAMPLE_DLY reg setting is lost after resume. The reason is that the reg may be reset to 0 after resuming, but dws->cur_rx_sample_dly doesn't know this fact. Fix this issue by clearing dws->cur_rx_sample_dly in dw_spi_shutdown_chip(). Signed-off-by: Jisheng Zhang Suggested-by: Mark Brown Link: https://patch.msgid.link/20260803135925.12622-1-jszhang@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e0bf6bed528693a6b32439ab122b34a34b66d96f 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 97b4740a6d620395c7a8729c10f8cd2c0d1815ea 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 b161eacd7fa4a2d765724b5504ac6cc388e48f80 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 8b921a8993469a3482e0c67b5ce5cb6ce93f5f61 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 945f6cde6bcf8f08f6fa5df8882b1b9582e55efa 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 498d3e85d26e38aab50f10d195849ce238c518e4 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 d11244a4fc4301ce35c6df3b7d980c1e9a6f3e8a 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 0f064ab57b3cf689b35c6956112fb03e28d59d78 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 73f8316994d5ff313457e5238a05f59c1df3116e Author: Markus Lindner Date: Wed Jul 22 03:09:18 2026 +0200 ALSA: usb-audio: Add dB map quirk for Razer Barracuda X 2.4 [ Upstream commit acd8aa3c4b91a38c8521000790890bc9d1083f1d ] The Razer Barracuda X 2.4 GHz USB headset dongle (0x1532:0x0552) reports a minimum volume register value of cval->min = -16800. In UAC 1/256 dB units, -16800 corresponds to -65.625 dB. However, stock ALSA misinterprets this raw integer as 1/100 dB units (-168.00 dB), causing user-space audio servers (PipeWire / PulseAudio) to map their volume curves against an incorrectly wide range. Add an explicit usbmix_dB_map entry overriding Unit 2 to -6562 (-65.62 dB) to accurately report the physical hardware attenuation bounds. Signed-off-by: Markus Lindner Link: https://patch.msgid.link/AS8P195MB2142F4EFF83980BD02BA6566E1C12@AS8P195MB2142.EURP195.PROD.OUTLOOK.COM Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c966203459456d722009c759afbfafb9b0ed67f7 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 15c6d7f7127a53b7312232178ecf03e5850161d2 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 1ae85bb34fe3510659b86d6a5f8036dd498233f8 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 31e1c350dd30523853f12edfd92c1f1bcd1d2ff1 Author: Kamal Wadhwa Date: Mon Jul 20 21:25:17 2026 +0530 regulator: core: clamp voltage constraints before applying apply_uV [ Upstream commit a45cc646a3aa83eb4ab4c7ed2685785ea51dc5e6 ] machine_constraints_voltage() currently applies apply_uV against the machine-supplied [min_uV, max_uV] range, and only afterwards clamps that range down to what the regulator can actually supply (via ops->list_voltage()). If the machine-supplied range is wider than the regulator's actual range, apply_uV's rounding can pick a selector outside the (correct) clamped range, so the regulator ends up programmed outside its clamped min/max. At bring-up this shows up as a voltage read-back outside the clamped range. Fix this by moving the clamping block ahead of the apply_uV block, so apply_uV always targets an already-clamped range. Whether apply_uV should run is decided from the unclamped constraints beforehand and stored in a local bool, since clamping must not itself change whether apply_uV fires. No functional change to the clamping logic itself, only its position relative to apply_uV. Its early return 0 exits become fallthroughs since the apply_uV logic now follows it. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260720-b4-regulator-core-clamp-voltage-v1-1-8e5eec076a8e@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4cb3d79beee0fecc739ce07af915d503f29ae557 Author: Jay Vadayath Date: Fri Jul 17 17:21:22 2026 -0700 smb: client: bound dirent name against end of SMB response in cifs_filldir [ Upstream commit f8cf09a53a0dc1da298e9dd0ba5f21710cf119d6 ] cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request. Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Jay Vadayath Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2fa102e9058b8bcf92052143e3f33de492b8f040 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 4f2ec7a0b3ff148cb13e14cb26ac43523df8b9f5 Author: Emmanuel Grumbach Date: Fri Jul 17 17:33:38 2026 +0300 wifi: iwlwifi: acpi: validate WGDS table revision index [ Upstream commit 954e821f42aaca56073ca830c5fd4bcf1a89048c ] Check tbl_rev bounds before BIT(tbl_rev) to avoid undefined shifts when firmware reports an invalid revision value. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717173215.52a01f841f2a.Ic0131eaac31d9ff71b169138d9b0865cb39b44a9@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit ed900c8952ce8ff47fe5444f864d98b68d27463f Author: Daniel C. Ribeiro Date: Sun Jul 19 06:00:37 2026 -0300 ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless [ Upstream commit f6d6a4147ace0c417035f65b021027c209c75190 ] JBL Quantum650 Wireless (0ecb:2125) requires the same workaround that was used for JBL Quantum610 and Quantum810 for limiting the sample rate. Without it, the capture (microphone) stream fails to work. Setting the QUIRK_FLAG_FIXED_RATE flag, as done for the sibling models, makes both playback and capture work correctly. Signed-off-by: Daniel C. Ribeiro Link: https://patch.msgid.link/20260719090037.40149-1-dcoutinho.96@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ce709fcab5e1d4df6d4ba980736dc5908502a40f 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 8c9e7265b3379eb2ce1758b73c4ffa2606ae2256 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 1f342b3e44c3035a837b53b217d816f7511c0d0a 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 d549b0c5d93100db173909e175e15e9e158beae2 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 ada8270ccdb6f212da5eb22614c28ea418746a4a 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 132de2e28489bfb672ccf6289cbcb105ffb30e72 Author: Marcel Kłos Date: Tue Jul 14 21:36:26 2026 +0200 ALSA: hda/realtek: Add quirk for HP EliteBook 830 G8 (8AB8) to enable mute LEDs [ Upstream commit 728d34ebf91c0e80b63a66b237dd0dfc5a8e5b4d ] The sound and microphone mute LEDs do not function on this newer revision of the board (8AB8) while they do on the older 880D models. I have verified this on another laptop which was manufactured before the one with the issue. Added the ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED from a G9 model, which uses the same codec, to make it work. Tested on kernel version 7.1.3 on the aforementioned newer revision notebook. Signed-off-by: Marcel Kłos Link: https://patch.msgid.link/4dab5622-9100-4730-8c99-b58da939549b@marmak.net.pl Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 358eca9a898ad4cce7453e9dcfd005d019a2b01f Author: Emmanuel Grumbach Date: Tue Jul 14 14:20:02 2026 +0300 wifi: iwlwifi: mvm: fix sched scan IE sizing [ Upstream commit 4f155d262b31b9b17e0f9856bdabe0968eb4930f ] Scheduled scan built the probe request before iwl_mvm_scan_fits(), so oversized IEs could be copied into the fixed preq buffer before length validation. Move iwl_mvm_build_scan_probe() after the fits check. Also advertise max_sched_scan_ie_len using iwl_mvm_max_scan_ie_len() so userspace limits account for driver-inserted DS/TPC bytes. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20260714141909.53d2722c79e7.Iebb922efa6173c92f14cd8aa8b4e7f372c0a0fb7@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 45fcdbae679861b90f08964a0c3e9eead3bacd6f 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 ee695a968aa73b1e67ccbf2133dc0e54381d32b2 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 beabdfdc2a48eae6b7ddfb615091149d9c6325ea Author: Wang YuWei <1973615295@qq.com> Date: Mon Jul 6 11:33:13 2026 +0800 spi: dw-dma: Wait for controller idle before completing Tx [ Upstream commit 0bcd59706aeda8a5d48ba656bab74cb26f2b423e ] dw_spi_dma_wait_tx_done() polls dw_spi_dma_tx_busy(), which only checks DW_SPI_SR_TF_EMPT. An empty TX FIFO merely means the last data word has been moved into the shift register; the transfer is not complete on the bus until DW_SPI_SR_BUSY is also cleared. As a result the wait can return while the controller is still shifting out the final word. Any caller that tears down or reconfigures the controller right after the transfer can then lose the tail of the transfer. The memory-operation path in spi-dw-core.c already waits for both DW_SPI_SR_BUSY == 0 and DW_SPI_SR_TF_EMPT == 1. Use the same completion condition in the DMA path so the transfer is guaranteed to be finished on the bus before the wait returns. Signed-off-by: Wang YuWei <1973615295@qq.com> Link: https://patch.msgid.link/tencent_4EA7B5C94669ED4C38A5F6C1C9126E5D9106@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9f599d120b2b79d2d937c3935b7cdf2697514283 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 8fa133411bc97013c9b873b9e2ee2475f007f3ee Author: Dave Chen Date: Fri Jun 26 14:45:24 2026 +0800 btrfs: only account delalloc bytes for regular file inodes in btrfs_getattr() [ Upstream commit 9411aafdf352b8d72668732af5a37dcb27383e25 ] btrfs_getattr() unconditionally reads BTRFS_I(inode)->new_delalloc_bytes and adds it (sector-aligned) to stat->blocks for every inode type. However, new_delalloc_bytes lives in a union with last_dir_index_offset: union { u64 new_delalloc_bytes; /* files only */ u64 last_dir_index_offset; /* directories only */ }; For a directory inode this memory holds last_dir_index_offset, which is set during directory logging (e.g. flush_dir_items_batch()) to the offset of the last logged BTRFS_DIR_INDEX_KEY. That offset grows with the number of entries ever created in the directory (dir indexes are monotonic and never reused), so it can be arbitrarily large. As a result, after a directory has been logged (e.g. via an fsync that triggers directory logging), btrfs_getattr() reports inflated st_blocks for that directory. The inflation is purely in-core and disappears after the inode is evicted and reloaded (btrfs_alloc_inode() zeroes the union), e.g. after a remount. Reproducer (on a btrfs filesystem): D=/mnt/btrfs/d mkdir -p $D for i in $(seq 1 20000); do touch $D/f$i; done sync # commit, push dir index high touch $D/trigger # dirty the dir in a new transaction xfs_io -c fsync $D # log the directory -> sets last_dir_index_offset stat -c '%b' $D # st_blocks is now inflated (e.g. 40) # umount + mount -> st_blocks drops back to the correct value The evict path already knows this union is type-dependent and guards the corresponding WARN_ON with !S_ISDIR() in btrfs_destroy_inode(); only btrfs_getattr() was missing the equivalent check. Only read new_delalloc_bytes for regular files, which are the only inodes that ever set it. Reviewed-by: Filipe Manana Signed-off-by: Dave Chen Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c6a3827b37137ada5fcae5d19c4c5bff33448e52 Author: Chen Bowen Date: Fri Jul 10 21:34:09 2026 +0800 ALSA: hda/realtek: Fix speakers on MECHREVO WUJIE Series [ Upstream commit 9064637fb2a80b43105900a47d414997630e5b6b ] The internal speakers on the MECHREVO WUJIE Series are silent, while the headphone output works correctly. The BIOS reports NID 0x1b on the Realtek ALC233 codec as unconnected with pin configuration 0x411111f0. However, the pin is connected to an internal speaker. Overriding NID 0x1b with 0x90170150 makes the HDA generic parser detect both 0x14 and 0x1b as speaker outputs and restores internal speaker playback. Add a pin configuration fixup for the affected PCI SSID c011:1d05. Tested on a MECHREVO WUJIE Series laptop with board WUJIE Series-Lark4-LNL and firmware EM_LNL326_V1.0.23. Signed-off-by: Chen Bowen Link: https://patch.msgid.link/20260710133409.16641-1-hicbowen@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7f99742c3c2801f8033d8b7a0a58254d7f24fb1e 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 eee5172741b2c0e73210020732043e5d589295d3 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 2836a870f612a8a6d9e390d00fa2cf6c90aa5808 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 64a8c3369f46984eed02313902f78be4900c2f36 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 ce2a3be6909462f49c34de96be71f0ad5f0d573f Author: Zhao Li Date: Tue Jul 7 10:53:34 2026 +0800 wifi: cfg80211: validate rx/tx MLME callback frame lengths before access [ Upstream commit d5e4586546974179feca305a94e07fac3e9727fe ] cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260707025336.22557-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cbdd23610f675fd54fedc5ff6a53dabbec4860d1 Author: Namjae Jeon Date: Wed Jul 1 22:58:35 2026 +0900 ksmbd: validate SID namespace before mapping IDs [ Upstream commit fbe0bb2b75eb3c61e8464486506253d1b471240b ] sid_to_id() currently treats the last subauthority of any owner or group SID as a Unix uid or gid. For example, this maps Everyone (S-1-1-0) to uid 0 and BUILTIN\Users (S-1-5-32-545) to gid 545. When an SMB2 CREATE security descriptor contains those SIDs, ksmbd attempts to change the newly created file to the bogus Unix ownership. notify_change() then returns -EPERM, which makes smb2.create.aclfile fail with NT_STATUS_SHARING_VIOLATION. Validate the SID prefix before extracting its RID. Only server-domain owner SIDs and S-1-22-2 Unix group SIDs have local ID representations. Treat other valid Windows SIDs as unmapped so their original values can still be preserved in the NT ACL xattr. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 71360125eea23d3d53cc188ba97af897240c5667 Author: Namjae Jeon Date: Thu Jul 2 19:37:53 2026 +0900 ksmbd: mark invalid session responses as signed [ Upstream commit 9e8ad620ddfde5a5f4ef58372e3805e9388cb0f4 ] When a signed request uses a session that is not registered on the connection, ksmbd returns STATUS_USER_SESSION_DELETED before reaching the normal response signing path. The response therefore lacks SMB2_FLAGS_SIGNED. Clients that require signing check this flag before handling STATUS_USER_SESSION_DELETED and replace the server status with STATUS_ACCESS_DENIED when it is absent. The protocol permits this error response to skip signature verification because the connection has no matching session key. Preserve SMB2_FLAGS_SIGNED on the early error response when the request was signed. This lets the client propagate STATUS_USER_SESSION_DELETED. It fixes smb2.session.bind2. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b1b6ed903a6e2b3505a48706bcd499b447ef9e44 Author: Namjae Jeon Date: Thu Jul 2 19:50:26 2026 +0900 ksmbd: find bound sessions during reauthentication [ Upstream commit faf8578c77f3d846aca9cd882c293e03eafcc6df ] A session bound to an additional connection is stored in the session channel list, but it is not added to that connection's local session table. After the binding exchange completes, conn->binding is cleared. A later SESSION_SETUP reauthentication on the bound channel only searches the local session table. It fails to find the session and returns STATUS_USER_SESSION_DELETED instead of processing authentication and returning STATUS_LOGON_FAILURE for invalid credentials. If the local lookup fails, look up the session globally and accept it only when the current connection is registered in its channel list. This keeps unbound connections from using the session while allowing reauthentication on an established channel. This fixes smb2.session.bind_invalid_auth. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3bcaaaa4ad334053ceea2ea2f0623f22afe2e1ac Author: Zhao Li Date: Tue Jul 7 10:53:35 2026 +0800 wifi: cfg80211: validate assoc response length before status and IE access [ Upstream commit b760113aeca2e9362d56bf9e9263373ffe6c8eb3 ] cfg80211_rx_assoc_resp() initialises the status and response-IE fields of cfg80211_connect_resp_params from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched resp_ie after the unsafe initialiser had already run. Defer resp_ie, resp_ie_len, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared free_bss label for the abandon paths. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260707025336.22557-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6576baa3fdbaa91fa75e4ba27095f4b8a27349a8 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 6b6690ac5c35e803df14afdc44312d11e8a60893 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 80d1a110e9096b5bf41497f6b151154084862385 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 349ea176632f29f04970444e0def108a337b562d 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 add9328c91c195c494cd68a21b19e5e47a20d784 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 686bb673b2cc57c39ae8c83e1d4eae61b9615434 Author: Namjae Jeon Date: Fri Jun 26 10:51:16 2026 +0900 ksmbd: fix credit charge calculation for SMB2 QUERY_INFO [ Upstream commit 284dc80ff529a0b454f11b6c2fea0d5daf6f315f ] smb2_validate_credit_charge() computes the credit charge a request is allowed to consume from the payload size: CreditCharge = (max(SendPayloadSize, ResponsePayloadSize) - 1)/65536 + 1 For SMB2 QUERY_INFO, the server must validate CreditCharge based on the *maximum* of InputBufferLength and OutputBufferLength. ksmbd instead summed the two lengths, which overestimates the required charge. As a result a single-credit QUERY_INFO whose InputBufferLength and OutputBufferLength each fit in 64KB but whose sum exceeds 64KB is rejected with STATUS_INVALID_PARAMETER, even though it is a valid request. IOCTL already uses max() of the request and response sizes; make QUERY_INFO consistent by feeding InputBufferLength as the request length and OutputBufferLength as the expected response length so that smb2_validate_credit_charge() takes their maximum. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 738098271680cb5f1f73fa94dd2c62d804e1fbc7 Author: Jetha Chan Date: Tue Jun 30 09:33:28 2026 +0900 ASoC: amd: yc: Add Alienware m15 R7 AMD to DMIC quirk table [ Upstream commit e782d687d2f5bf8b8113dc48ba22cca4b472c252 ] The Alienware m15 R7 AMD exposes an ACP6x DMIC path, but its DMI product name is not present in the Yellow Carp ACP quirk table. As a result, the ACP machine driver does not enable the DMIC card on this system. Add the DMI product name for this machine. With this quirk applied, the kernel reports: acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI and ALSA exposes the ACP DMIC capture device: card 3: acp6x device 0: DMIC capture dmic-hifi-0 Tested on an Alienware m15 R7 AMD with product SKU 0B59. Link: https://jethachan.net/dev/2026/03/21/fixing-internal-microphone-alienware-linux.html Assisted-by: OpenAI-Codex:gpt-5.5 Signed-off-by: Jetha Chan Link: https://patch.msgid.link/20260630003328.15675-1-jethachan@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e582a3e99584d5a634a3cbce4b12e9381fd5d964 Author: David Howells Date: Thu Jun 25 15:06:21 2026 +0100 cachefiles: Fix double fput [ Upstream commit af6830cc12dfe86c832dccc9c9878a93aaa22f83 ] Fix a double fput() in error handling in cachefiles_create_tmpfile(). Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-4-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 83b76e45c7b121ae46fff3703951c3beebb3e8ff Author: Namjae Jeon Date: Fri Jun 26 10:52:22 2026 +0900 ksmbd: fix outstanding credit leak on abort and error paths [ Upstream commit 4a0b7826615a01c47924334a2e8a9dbd84a598b2 ] smb2_validate_credit_charge() adds the request's CreditCharge to conn->outstanding_credits when an SMB2 PDU is received, and smb2_set_rsp_credits() subtracts it again when the response is built. However smb2_set_rsp_credits() only runs on the normal response path: - __process_request() returning SERVER_HANDLER_ABORT (unimplemented command, command index out of range, signature check failure, or a handler that sets send_no_response such as a cancelled blocking lock) breaks out of the processing loop before set_rsp_credits() is called; - smb2_set_rsp_credits() itself returns early with -EINVAL (total credit overflow or insufficient credits) before the subtraction. On all of these paths the charge added at receive time is never returned, so conn->outstanding_credits only grows. Because a client can repeatedly trigger them (e.g. by sending unimplemented commands or by issuing and cancelling blocking locks), outstanding_credits eventually reaches total_credits and smb2_validate_credit_charge() then rejects every subsequent request, wedging the connection. Record the charge that was added in work->credit_charge and release any charge still pending at the single send. exit point of __handle_ksmbd_work(), which all abort and error paths fall through to. smb2_set_rsp_credits() clears work->credit_charge once it has returned the charge so the response path is unchanged and the credit is never released twice. Paths that never charged a credit (no multi-credit support, validation failure) leave work->credit_charge at zero and are unaffected. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 641de086a05f349de7fc548612432bc2fed721ca 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 f1f2d54a576f0e4133b979e545abcfefd439c300 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 b99632824133aa68c479d7b9efce4e352e9f13db 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 86c2625fb9863139b359805fc6be1e31edbd3d65 Author: Qiang Liu Date: Wed Jun 24 09:13:19 2026 +0800 ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling [ Upstream commit d708a36634bb7b6f94d0e76d587d2ec50b2b93b5 ] 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer. Signed-off-by: Qiang Liu Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6a07bfad69307593e4d6fd4ec260aaa410b96ec1 Author: Qiang Liu Date: Wed Jun 24 09:13:20 2026 +0800 ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr [ Upstream commit 7ac657bb9c5c1b0f7bdf1fa6d3ad532f969be5cf ] Free ndr buffer data when ndr_encode_dos_attr() returns error to avoid memory leak. Signed-off-by: Qiang Liu Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3dd4adb56109d5d5a1d325d24d2fefdbf9a13c50 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 dc55270e410ccb4d24e637c13b5c4c25bcd106d7 Author: Qiang Liu Date: Wed Jun 24 09:13:18 2026 +0800 ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr [ Upstream commit d4d56b00c7df88cd5751e7415bdfabc9fdbc82a7 ] ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths. Signed-off-by: Qiang Liu Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9c11d7ea5ff4dbe162e79f00188814ef5483c295 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 661d5bbc6f8904ecc75e753740c1e5716af59b27 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 509d6a4d889e425f305461d8323a7b39ca6c121c Author: Weiming Shi Date: Thu Jun 11 07:56:12 2026 +0930 btrfs: tree-checker: validate INODE_REF's namelen [ Upstream commit 3dc22abc21f5892406c09202fa2627196cc96967 ] [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 index 2 namelen 4096 name: d\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 Reported-by: Xiang Mei Link: https://lore.kernel.org/linux-btrfs/aik0hEV6ehKx6Ldv@Air.local/ Acked-by: Weiming Shi Signed-off-by: Weiming Shi [ Rebase, add a Link: tag, add an simple cause analyze ] Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a75d9eb78c89d3fa8d503966c91a51f02eced768 Author: Praveen Talari Date: Thu Jun 25 21:26:02 2026 +0530 spi: core: Abort active target transfer on controller suspend [ Upstream commit c1bab046d4786c5b17aab7c5225bf0d4a2a2d19b ] When an SPI controller operating in target mode has a transfer in progress at the time of system suspend, the suspend path proceeds without aborting the ongoing transfer. This can leave the hardware in an inconsistent state, potentially causing the system to hang or fail to resume cleanly. Fix this by invoking the controller's target_abort callback from spi_controller_suspend() when the controller is in target mode and the callback is registered. This ensures any active target transfer is cleanly terminated before the controller is suspended. Signed-off-by: Praveen Talari Link: https://patch.msgid.link/20260625-abort_active_transfer_duirng_s2r-v2-1-1d6f724406b6@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8e9a75ef9a02a1780ffbdb3643befab60673ef69 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 f8a29061a699d5dc803d35d61b5750c56255bde8 Author: Arnd Bergmann Date: Mon Jun 22 14:41:07 2026 +0200 eth: mlx5: fix macsec dependency [ Upstream commit 87ab8276ed24d688febfef4d0c1794896e778192 ] Configurations with mlx5 built-in but macsec=m fail to link: x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_add_gid_macsec_operations': macsec.c:(.text+0x77d): undefined reference to `macsec_netdev_is_offloaded' x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_del_gid_macsec_operations': macsec.c:(.text+0xe81): undefined reference to `macsec_netdev_is_offloaded' Fix the dependency so this configuration cannot happen. Signed-off-by: Arnd Bergmann Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260622124229.2444502-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 43075df51ef5a59c9a7ed69b61bfdeafd6417d36 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 ad5b3f6a4b4b9c60f15429490a34da66858d7508 Author: Yu Kuai Date: Mon Jun 8 11:42:42 2026 +0800 blk-cgroup: protect iterating blkgs with blkcg->lock in blkcg_print_stat() [ Upstream commit 25656304dabd26198ec69460c594a19d086ef099 ] blkcg_print_one_stat() will be called for each blkg: - access blkg->iostat, which is freed from rcu callback blkg_free_workfn(); - access policy data from pd_stat_fn(), which is freed from pd_free_fn(), while pd_free_fn() can be called by removing blkcg or deactivating policy; Take blkcg->lock while iterating so the blkgs stay online and both blkg->iostat and policy data for activated policies stay valid. Use irq-safe locking because blkcg->lock can be nested under q->queue_lock, which is used from IRQ completion paths. Prepare to convert protecting blkgs from request_queue with mutex. Signed-off-by: Yu Kuai Link: https://patch.msgid.link/05799877e720dcd300e2ddd4625e8e162959d7cc.1780621988.git.yukuai@fygo.io Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d514b08ed61fdffe23604fd3e9e53c07cbe5ac3e 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 715c41bb6df52f43ab22e67eb89debee578ea2dc Author: Pengpeng Hou Date: Wed Jun 24 14:00:24 2026 +0800 regulator: da9121: Use subvariant ids in the I2C table [ Upstream commit 7ddbf1cde4a03e36e17d06fbc711870eb0b256d7 ] da9121_i2c_probe() stores i2c_get_match_data() in chip->subvariant_id and da9121_assign_chip_model() switches on DA9121_SUBTYPE_* values. The OF table provides those subvariant values, but the I2C id table currently provides DA9121_TYPE_* values. Make the I2C id table use the same subvariant namespace as the OF table so non-DT I2C matches feed the expected data type into the model assignment code. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260624060024.61300-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 53f581f4d51d859a40e4a77623242501362d2579 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 c346a867d4746a77a5f1bc7e6da5bfc6a774a348 Author: Krzysztof Wilczyński Date: Thu Jun 11 15:05:43 2026 +0000 PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device() [ Upstream commit 8857f6578b001bcf5f53c8c6a3936647f05291a8 ] pci_proc_attach_device() creates procfs entries for PCI devices and is called from pci_bus_add_device(). It lazily creates the per-bus procfs directory (bus->procdir) via proc_mkdir() on first use, and returns early if proc_initialized is not yet set. On x86 with ACPI, PCI enumeration occurs at subsys_initcall, before pci_proc_init() sets proc_initialized at device_initcall. The for_each_pci_dev() loop in pci_proc_init() then creates procfs entries for these already-enumerated devices, but runs without holding pci_rescan_remove_lock. On ARM64 with devicetree, PCI host bridges probe at device_initcall. With async probing enabled, pci_bus_add_device() can run concurrently with pci_proc_init(), and both may call pci_proc_attach_device() for the same device or for different devices on the same bus. As pci_host_probe() holds pci_rescan_remove_lock while pci_proc_init() does not, there is no serialisation between the two paths. When two threads concurrently call pci_proc_attach_device() for devices on the same bus, both observe bus->procdir as NULL and both call proc_mkdir(). The proc filesystem serialises directory creation internally, so only one caller succeeds. The other results in a warning like: proc_dir_entry '000c:00/00.0' already registered The caller receives NULL (duplicate entry) and unconditionally stores it to bus->procdir, corrupting the valid pointer set by the first caller. Serialise access to proc_initialized, proc_bus_pci_dir, bus->procdir and dev->procent with a new mutex local to drivers/pci/proc.c, and store the created entries to bus->procdir and dev->procent only on success, so a failed creation can never overwrite a valid pointer. Additionally, wrap the for_each_pci_dev() loop in pci_proc_init() with pci_lock_rescan_remove() to serialise against concurrent PCI bus operations, add an early return in pci_proc_attach_device() when dev->procent is already set to make the function idempotent, and clear bus->procdir in pci_proc_detach_bus() to prevent use of a dangling pointer after proc_remove(). Reported-by: Shuan He Closes: https://lore.kernel.org/linux-pci/20250702155112.40124-2-heshuan@bytedance.com/ Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20260611150543.511422-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 0facff6396ea66245671ed08c56e3a9098b48a21 Author: Namjae Jeon Date: Thu Jun 18 21:33:07 2026 +0900 ksmbd: break RH leases before delete-on-close [ Upstream commit 1f1083c36fa11c5d9011451c7b9ab380545c72ea ] The delete paths only marked the opened file delete pending or delete-on-close. When another client still held a read/handle lease, no lease break was sent before the delete state changed. smb2.lease.unlink uses a create request with FILE_DELETE_ON_CLOSE and expects the second client's unlink to break the first client's RH lease to R with ACK_REQUIRED set. SetInfo(FileDispositionInformation) has the same lease-breaking requirement. Break level-II/read-handle leases before setting delete pending or delete-on-close so clients are notified before the file is removed. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 31c9cdcc96e951eb7f5008f4d756a7300655e651 Author: Namjae Jeon Date: Sun Jun 21 19:59:06 2026 +0900 ksmbd: start file id allocation at 1 [ Upstream commit 6b375be0b4e1be89e9a817880515311503a19114 ] ksmbd allocates both the volatile id (per-session file table) and the persistent id (global file table) with idr_alloc_cyclic() starting at 0. The first open after the module loads therefore gets volatile id 0 and persistent id 0, and ksmbd returns an SMB2 FileId of {0, 0} in the create response. Clients treat an all-zero FileId as a null handle. smbtorture's smb2_util_handle_empty() considers {0, 0} empty, so tests that guard the close with it (e.g. smb2.oplock.statopen1, smb2.lease.statopen*) never close that first handle. The leaked open keeps the inode's oplock count non-zero, so a later batch oplock request on the same file is downgraded to level II and the test fails. Start the id allocation at 1 (KSMBD_START_FID) so no handle is ever assigned a {0, 0} FileId, matching the behaviour of other SMB servers. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a39e2146968f927337a13486417b63c7368ec8ac Author: Namjae Jeon Date: Sun Jun 21 19:47:56 2026 +0900 ksmbd: apply create security descriptor first [ Upstream commit ba3cf6ee4f0eacc1f8c607b80188e3b32ef5e0e3 ] smb2.create.aclfile creates files with an SMB2_CREATE_SD_BUFFER create context and expects the resulting security descriptor to match the descriptor supplied by the client. ksmbd currently tries to inherit the parent DACL first and only parses the SMB2_CREATE_SD_BUFFER context when DACL inheritance fails. If inheritance succeeds, the explicit security descriptor supplied on create is ignored. This breaks create requests that include owner/group information in the security descriptor. Apply the create security descriptor first when the context is present. Fall back to the existing inherited/default ACL path only when no create security descriptor was supplied. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 71f2ea5dd62d10a209b0e382fcbd9ab2d8b4060d Author: Namjae Jeon Date: Thu Jun 18 10:36:17 2026 +0900 ksmbd: treat unnamed DATA stream as base file [ Upstream commit 171b5d72dd80f99271c073c6e38d5263687c3b6d ] The SMB path suffix :: names the unnamed data stream of the base file, not an alternate data stream backed by a DosStream xattr. Canonicalize an empty stream name with an explicit type to a NULL stream name after parsing. This keeps the base filename produced by strsep() and lets open continue through the normal base-file path instead of looking for a non-existent empty stream xattr. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c77d091ed4e17f3f11738be509892fc8d39edaa4 Author: Namjae Jeon Date: Thu Jun 18 10:33:20 2026 +0900 ksmbd: use connection ClientGUID for lease lookup [ Upstream commit fa111daae1a02dbff5693dfc12f368bccd9eb5f4 ] MS-SMB2 defines the lease table lookup key as Connection.ClientGuid. Use the connection ClientGUID consistently when checking for same-client leases and duplicate lease keys. Also preserve directory and parent lease metadata when copying an existing lease state to a new open. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 725449e086b7444ab6ef09c845a4ab734e3a4ad7 Author: Namjae Jeon Date: Thu Jun 18 10:35:42 2026 +0900 ksmbd: align SMB2 oplock break ack handling [ Upstream commit 80a56d4a826c6c84430286fcf7d8655f7c5b0868 ] Handle SMB2 oplock break acknowledgments according to the server-side validation rules in MS-SMB2. Return STATUS_INVALID_DEVICE_STATE when an ACK arrives while the open is not breaking, reject SMB2_OPLOCK_LEVEL_LEASE with STATUS_INVALID_PARAMETER, allow BATCH acknowledgments to EXCLUSIVE, and make invalid ACK levels fail with STATUS_INVALID_OPLOCK_PROTOCOL after lowering the oplock to NONE. Update the successful response from the final granted oplock level instead of relying on the oplock transition helpers, which could turn invalid ACKs into successful responses. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b386b66a3b88c22f6032f405c807bfa2c22e6fc8 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 4dd81faa63fd54b9ba1a83c304e6d0bd03f1898d 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 628b14d0744bd5dfe176ea93559071cdcde14255 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 381bf7a2ba88d0890cab5dd82d8075732040be8c Author: Yu Kuai Date: Fri Jun 5 15:26:37 2026 +0800 md/raid5: account discard IO [ Upstream commit 74ddbf98e2db646ec58f7e7731c936b7a4a470fe ] Raid5 handles discard bios internally through make_discard_request() and never passes them through md_account_bio(). As a result, discard IO is missing the md-device iostat accounting that normal raid5 IO and discard IO in other raid levels get from md_account_bio(). Before accounting the bio, trim the request to the full data stripes that raid5 will actually discard. The first full stripe is the ceiling of the bio start divided by data-stripe sectors, and the last full stripe is the floor of the bio end divided by data-stripe sectors. Account that exact MD logical full-stripe range, then restore the original iterator so bio completion and iostat still cover the original request. Link: https://patch.msgid.link/20260605072639.2434847-2-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 8d910649725955435c6a807944108bca0570712d 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 eaeb9bed3641741aceb0add84a97023bed61e748 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 442b7f2a093b4a75f8963aaa7cbb2b8df35a6ac3 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 4e1d34d824050a4e700ca442f815a95d9f214b83 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 929892fc214e3eb35e953bac777159bd03862265 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 2b0870e51222d2f914cf035d3f1239825e79955b Author: Matthew Bystrin Date: Wed Apr 29 10:20:47 2026 +0300 mfd: rsmu: Add 8a34002 support [ Upstream commit d18fd55c780c2bae3d353024cab7f8746d3d9e91 ] Add compatible string, i2c_devcie_id and spi_devcie_id to support 8a34002. Signed-off-by: Matthew Bystrin Link: https://patch.msgid.link/20260429072047.1111427-3-dev.mbstr@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 70e889b91fb0af700327f02879a727fe2bfa0bb5 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 e5a505cf2d79cd2a87992a10f0b3defca9469548 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 9534eb14ca9689fefddbe6ed2b46f3aa390b5cb6 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 c4896592744f30ff026f799947c5978bcfd7c8c7 Author: Jakub Kicinski Date: Sat Jun 13 18:40:56 2026 -0700 tls: reject the combination of TLS and sockmap [ Upstream commit 460e6486617c17dd19abe8f3fc67d9a6fa25f8ca ] TLS and sockmap (BPF psock) integration hides a lot of latent bugs. Bugs which may be more or less relevant for real users but they are definitely exploitable. We could not find anyone actively using this integration so let's reject this config. Adding a TLS socket to a sockmap was already rejected by sk_psock_init() through the inet_csk_has_ulp() check. We need to reject the attempts to configure the TLS keys (rather than adding the ULP itself) because checking prior to the ULP installation is tricky without risking a race with sockmap getting added in parallel (sockmap does not hold the socket lock). This patch is a minimal rejection of the feature. Subsequent patch in the series will do a light dead code removal. Full cleanup would require a major rewrite of the Tx path, we don't need skmsg any more. Reviewed-by: Jakub Sitnicki Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260614014102.461064-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c46cd6bc454943881963c8858a1ae99936e71d99 Author: Ai Chao Date: Wed Jun 17 10:52:34 2026 +0800 ALSA: usb-audio: Add quirk flags for SC13A [ Upstream commit 8956950dab22fbaefe92ca1980728165c5da793d ] The SC13A ( VID 0x1ff7, PID 0x0f81) not support reading the current sample rate and results in an error message printed to kmsg. Set QUIRK_FLAG_GET_SAMPLE_RATE to skip the sample rate check. Quirky device sample: usb 3-5.2.4.1: new high-speed USB device number 11 using xhci_hcd usb 3-5.2.4.1: New USB device found, idVendor=1ff7, idProduct=0f81 usb 3-5.2.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-5.2.4.1: Product: SC13A usb 3-5.2.4.1: Manufacturer: Linux Foundation usb 3-5.2.4.1: SerialNumber: 000002 usb 3-5.2.4.1: Found UVC 1.50 device SC13A (1ff7:0f81) usb 3-5.2.4.1: 3:1: cannot get freq at ep 0x86 usb 3-5.2.4.1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. usb 3-5.2.4.1: [5] FU [Mic Capture Volume] ch = 1, val = 0/4096/1 usbcore: registered new interface driver snd-usb-audio usb 3-5.2.4.1: 3:1: cannot get freq at ep 0x86 usb 3-5.2.4.1: 3:1: cannot get freq at ep 0x86 Signed-off-by: Ai Chao Link: https://patch.msgid.link/20260617025234.3344935-1-aichao@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aa966ccea3584a70c9a6030f4a16577030db35e5 Author: guoqi0226 Date: Tue Jun 16 18:30:18 2026 +0800 spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() [ Upstream commit f1b061b4d4c6cbf861319ba954caa80145cf018f ] Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry. Signed-off-by: guoqi0226 Link: https://patch.msgid.link/20260616103018.105612-3-guoqi0226@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 53d4b76b476c7d4329fa25b380483c41f450b3ba 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 5e088415eb8a80872bb6226fa1b2a0db0637c4e9 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 5136938846e034608adc09f14166d8c2e7e6c821 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 e03fd646adad7f97fa4429ec5f38cee9bde5276e Author: Jiri Kosina Date: Fri Jun 12 17:48:22 2026 +0200 HID: hidpp: fix potential UAF in hidpp_connect_event() [ Upstream commit 6df6b1f2c49678211f65647c300bc51dda02893b ] If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event(). Reported-by: zdi-disclosures@trendmicro.com Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9642606a7bc0013ecad7430c475a35a6f7ffa900 Author: Viktor Menshin Date: Mon Jun 15 18:25:15 2026 +0900 ALSA: hda/realtek: Add quirk for Lenovo Xiaoxin 14 GT [ Upstream commit 3a3e810e91080a5121170ee11554a55ed89a1c8b ] The Lenovo Xiaoxin 14 GT (Chinese market model, AMD Ryzen AI 9 365) produces constant electrical hissing and crackling noise from both internal speakers and 3.5mm headphone jack during audio playback. Audio works correctly on Windows. The PCI SSID 17aa:3912 is not present in the quirk list. The device shares the same AMD platform and ALC287 codec as neighboring Lenovo 14" AMD models (17aa:3911, 17aa:390d), so apply the same fixup. Note: the fixup selection is based on similarity with neighboring models and has not been verified by testing a compiled kernel. Guidance from maintainers on the correct fixup is welcome. Signed-off-by: Viktor Menshin Link: https://patch.msgid.link/20260615092515.1082-1-ripeeerr@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4859f843d93d7efb8f379eda6b71dcfc5bbe1681 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 ac97e78a9734b1c4b7eae285459e79de383a58b4 Author: Adrian Hunter Date: Fri Jun 12 11:01:04 2026 +0300 i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in DAA [ Upstream commit c236563c8a84239d31a1e6ec4444887a7b5ed98f ] i3c_master_add_i3c_dev_locked() no longer leaves the address marked as free on failure, so aborting the DAA sequence on its error is unnecessary. Failure to register a discovered device does not invalidate the entire Dynamic Address Assignment (DAA) procedure. Align with the behavior of other I3C master drivers by ignoring errors from i3c_master_add_i3c_dev_locked() and continuing enumeration. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260612080107.11606-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 017b88a0b1a1cfec118c5e64471fe1269f248813 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 b5bde437f8bae1253f796d8508601d90392acf7c 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 3656c6377402090d2023ef4ec75a0363c56a52af 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 e818a40ad00de2e25649a8f18a4ddbd54752250d Author: Vadim Fedorenko Date: Thu Jun 11 19:03:33 2026 +0000 ptp: ocp: add shutdown callback [ Upstream commit f6f955cbf9d4e02deebe54ca91c118b53be9ffe6 ] The shutdown callback was never implemented for this driver, but it's needed because .remove() callback is never called during kexec/reboot process. That leaves HW with some interrupts enabled and may cause spurious interrupt while booting into a new kernel during with kexec. If it happens that I2C interrupt fires during kexec, the whole I2C bus is disabled leaving TimeCard with no devlink communication. The same happens if timestampers were enabled, leaving the card without timestamper interrupts until full reboot cycle. Implement .shutdown() callback with the same function as remove callback. Signed-off-by: Vadim Fedorenko Link: https://patch.msgid.link/20260611190333.787132-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b3b91433d5f4eae6865cdaa96f40cd67849e1f6 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 5b9defb393ce77b5840b6da3023aae548551b1b5 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 bbba86135db6a883585c5a694f06823631c4019a 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 00acf839c41ad43744f35b21ece06fe704f98afd 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 52b77346cf66174ab9bc34504729cd686a9e29b1 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 22fc1ce4e37c81d4e7aac01566ebdc232214540d 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 0743aca879298c7fee9e0ae60f365bd10f361358 Author: Cris Date: Wed Jun 3 11:58:18 2026 +0800 Bluetooth: btusb: Add support for TP-Link TL-UB250 [ Upstream commit ea77debfe443f505a4edbb7f21340a583a8a143f ] Add USB ID 2357:0607 for TP-Link TL-UB250. This is a Realtek RTL8761BUV based Bluetooth adapter. Without this entry the device is picked up by the generic Bluetooth USB class match and exposes hci0, but the Realtek setup path is not used and rtl8761bu firmware/config are not loaded. The controller reports Realtek Semiconductor Corporation as the manufacturer and LMP subversion 0x8761. With this entry added, btusb loads rtl_bt/rtl8761bu_fw.bin and rtl_bt/rtl8761bu_config.bin successfully. Relevant part of /sys/kernel/debug/usb/devices: T: Bus=01 Lev=02 Prnt=06 Port=00 Cnt=01 Dev#= 9 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2357 ProdID=0607 Rev= 2.00 S: Product=TP-Link TL-UB250 Adapter C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Use the same flags as the existing TP-Link 2357:0604 entry. Reviewed-by: Paul Menzel Signed-off-by: Cris Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ad6dbe5308825cf2cefa1db06b9381d125bd9d93 Author: Hrvoje Nuic Date: Wed Apr 22 23:26:47 2026 +0200 Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV [ Upstream commit ce21a5cf3d1fd92b84ea9ad2b7c7240aff2162d2 ] Add the USB ID for the Mercusys MA530 Bluetooth adapter. The device uses a Realtek RTL8761BUV controller and works with the existing Realtek setup path. The device reports vendor ID 0x2c4e and product ID 0x0115, and loads the rtl_bt/rtl8761bu_fw.bin firmware successfully with this quirk. Signed-off-by: Hrvoje Nuic Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c1ba25390f1bbb52034c58829a1f1f2046d72eba Author: Vadim Fedorenko Date: Wed Jun 10 22:28:43 2026 +0000 spi: xilinx: let transfers timeout in case of no IRQ [ Upstream commit 0f95264f49ace739d411fd9149e2b3545d741d06 ] In case of failed HW the driver may not see an interrupt and will stuck in waiting forever. We can avoid such situation by timing out of transfers if the interrupt is not seen in a reasonable time. This problem can be found on unload of ptp_ocp driver for TimeCard which uses Xilinx SPI AXI and SPI-NOR flash memory. During tear-down process spi-nor drivers send soft reset command which is not triggering an interrupt stalling the unload process completely. Signed-off-by: Vadim Fedorenko Acked-by: Michal Simek Link: https://patch.msgid.link/20260610222843.782337-1-vadim.fedorenko@linux.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b6c72b7f9fbfb87ae3213754696fa96c10c520de 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 088bbc4045405af52ca5c11a936c1514bd58a80d Author: Tze Yee Ng Date: Mon May 25 00:10:22 2026 -0700 dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc [ Upstream commit df0c2dc68770cf43f15df40b184df030b850ea05 ] The driver only had runtime PM callbacks. If a channel stayed allocated across system suspend/resume, the runtime usage count could remain non-zero while hardware state (DMAC_CFG, clocks) was lost, and axi_dma_runtime_resume() would not run to restore it. Add system-sleep PM ops that use pm_runtime_force_suspend() and pm_runtime_force_resume() so suspend/resume reuses the existing axi_dma_suspend() and axi_dma_resume() paths. Replace pm_runtime_get() with pm_runtime_resume_and_get() in dma_chan_alloc_chan_resources() so clocks are enabled before a client can immediately submit a transfer and touch MMIO. Signed-off-by: Tze Yee Ng Link: https://patch.msgid.link/18bf778a3a1cc2f377ef8eb0d1508d8ac6371896.1779688569.git.tze.yee.ng@altera.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f9913930a3cb65fea46f20899691fd72607d3570 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 182b29345d020109e7deeefd4bd7fa9003aad443 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 94c90fc74f77d1e650b8ab1a4f27f2e841382d21 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 59021914158386dc17454b451d03e0733e898bb4 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 d8a221ecb8b239dd288219294d868380ae83f6dd Author: Furst Blumier Date: Tue Jun 9 22:17:06 2026 +0200 ALSA: hda/realtek: Add quirk for HP 255 15.6 inch G9 Notebook PC [ Upstream commit 98e157916f83c26a41448267180944048d2f1460 ] The HP 255 15.6 inch G9 Notebook PC (PCI SSID 103c:8a1b) uses the ALC236 codec but lacks an entry in the quirk table, causing the kernel to fall back to a null SSID match (103c:0000) and skip the necessary fixup. Add a quirk entry using ALC236_FIXUP_HP_MUTE_LED_COEFBIT2, matching the HP 255 G8 which uses the same codec and fixup. This fixes the mute-button LED and fixes an issue with unplugging and replugging a headset jack not being recognized as an audio sink. Signed-off-by: Furst Blumier Link: https://patch.msgid.link/20260609201706.502075-1-seal@furst.blue Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5fa38a188e5838ca1a45e6f3ef76104dc2dcdce7 Author: Evgenii Burenchev Date: Thu Feb 26 18:29:23 2026 +0300 vdpa/ifcvf: handle dev_set_name() failure in ifcvf_vdpa_dev_add() [ Upstream commit 4c653e85857b41a7148917f2628fae1d04a9c251 ] dev_set_name() may fail and return an error, but its return value is currently ignored and overwritten by _vdpa_register_device(). Abort device creation if dev_set_name() fails and release the device reference to avoid continuing with an improperly initialized struct device. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Evgenii Burenchev Acked-by: Jason Wang Acked-by: Zhu Lingshan Signed-off-by: Michael S. Tsirkin Message-ID: <20260226152924.38790-1-evg28bur@yandex.ru> Signed-off-by: Sasha Levin commit 8ad8f95ff667e8f191857de99796937af6300b8e 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 a0dc28359a8a26f970ccd250b126a2e0bd4118a5 Author: KangNing Liao Date: Thu May 21 20:29:45 2026 +0800 btrfs: protect sb_write_pointer() with invalidate lock [ Upstream commit 123b9a545f4d0348e81f558a032bf2a93ee5722f ] sb_write_pointer() reads the super block from the block device page cache using read_cache_page_gfp(). This has the same race with BLKBSZSET as the one fixed by commit 3f29d661e568 ("btrfs: sync read disk super and set block size"). Take the mapping invalidate lock around read_cache_page_gfp() to serialize the read against block size changes. Signed-off-by: KangNing Liao Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e76084fee6d3a3f26e19fa2259e117923840532c 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 4a780261e4acbdb2fa13bb5d04ed0b3dcedef173 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 62126e73e230cf4bd6c27cf201949c4290af84a1 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 6871b48733687eb77742e7dcb4840639258470a8 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 de9c50bd70a7e29fd3bfc6ce44051bd6133a41cc 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 2c52b2afded988233cd4ccc185cf5147bbc77a76 Author: Aurelien DESBRIERES Date: Mon Jun 8 15:47:15 2026 +0200 RDMA/rtrs-srv: Fix integer underflow in process_read and process_write [ Upstream commit 54bf38b27afc08a0eb6b732f9c14eb8a4bcb66b5 ] usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak. Link: https://patch.msgid.link/r/20260608134802.5019-1-aurelien@hackers.camp Reported-by: Aurelien DESBRIERES Reviewed-by: Md Haris Iqbal Signed-off-by: Aurelien DESBRIERES Assisted-by: Claude Acked-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 84ec14fa0294778ad8705b5273c00230c3ca252c Author: Dai Ngo Date: Thu Apr 23 10:52:10 2026 -0700 NFS: fix eof updates after NFSv4.2 fallocate/zero-range [ Upstream commit 35168eb947f230aaa35fd8416a30563ef89f5421 ] Generic/075 reliably exposes a regression when the client holds an NFSv4 write delegation: ZERO_RANGE/ALLOCATE extends the file on the server, but the local inode keeps the old i_size. The test then fails with 'Size error' because the post-op attribute refresh refuses to touch i_size while a delegation is outstanding, and the cached EOF was never marked stale. Update _nfs42_proc_fallocate() so that on success it: - bumps i_size when the operation extends the file, and - marks NFS_INO_INVALID_BLOCKS since the block count can also change Tested with xfstests generic/075 over NFSv4.2. Signed-off-by: Dai Ngo Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 1370badf6b823ce3cde39a65f46f9e5dc7b4bf43 Author: Zhang Cen Date: Mon May 11 15:01:28 2026 +0800 btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF [ Upstream commit 0af37c217edf15fa21dac1c40822086df356c6bb ] ROOT_REF and ROOT_BACKREF items contain a struct btrfs_root_ref followed by the subvolume name. Several readers assume that this layout is already valid and then use the on-disk name length directly. A corrupted item can therefore make those readers address bytes outside the item, and BTRFS_IOC_GET_SUBVOL_INFO can copy too many bytes into its fixed-size UAPI name buffer. Validate ROOT_REF and ROOT_BACKREF items in tree-checker before any reader uses them. Reject records that do not contain a non-empty name, whose name_len does not exactly describe the remaining item payload, or whose name exceeds BTRFS_NAME_LEN. For BTRFS_IOC_GET_SUBVOL_INFO, copy only the validated on-disk name_len instead of deriving the copy length from the item size. The ioctl result is zeroed when allocated. That leaves the existing trailing zero byte untouched. Reviewed-by: Qu Wenruo Signed-off-by: Zhang Cen Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 322f891b4d4fe64acb3351a0ffa62a7fa5ba7256 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 55bcc3376cd7b18954cc9814da697504fdaf12bf 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 3d8adddf4e4a5a43847ee62e5e78ba05e756bdef 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 9bf45feee630be868ab54e3d0f3d430c07471f0e 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 43d4af5c5331ea739a49cb1097d41e502ed91ec4 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 36d3e9f62dc2beb9299d3bb6f589cb9e07f773fe 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 2c859488679e9d88eb8ac7856cd58e6da13a569c 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 ddccf6cc3861de2fe60986933bead79220e0d797 Author: Jason Gunthorpe Date: Mon Jun 1 13:52:32 2026 -0300 RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() [ Upstream commit 09ea6837a0434fb4db99528a5055b6d822135dcf ] Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK Link: https://patch.msgid.link/r/2-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 914c5b7dc6735a35324653e42d8b10abae33b4bf 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 bdfa0383162c9b475bbec9c4ada5b669aead45e8 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 934b0f70159a910393294ee8b6ba32a96a6922f1 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 5db1e7f7e10a3e8b5c542290088c3044ae1b47a1 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 6e723f7996f3b01c1fbf5acbf75193a45187c367 Author: Cyrill Gorcunov Date: Fri May 29 01:30:11 2026 +0300 RDMA/irdma: Fix typo in SQ completions generation [ Upstream commit b548a6c4eee5c428663f3944e173e6c92e2e8d6f ] When we generate completion for SQ the opcode while being properly read from ring buffer is ignored when written back to completion. Seems to be a simple typo. Link: https://patch.msgid.link/r/ahjB87k54bYdFbft@grain Signed-off-by: Cyrill Gorcunov Reviewed-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit abe61d067b48b947bedc9bae3725cb8f48dc8c0a Author: Asad Kamal Date: Tue May 12 15:44:32 2026 +0800 drm/amd/pm: bound pp_dpm_set_pp_table() memcpy [ Upstream commit f193e71fa9fab2e68ef85201b106e8f580d3a25b ] The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size. Signed-off-by: Asad Kamal Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a215190ef68ca3602fe00674e0efffad71beb3aa 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 bd16f46d0796109d241d6311a7577f9956467c96 Author: Ioana Ciornei Date: Thu May 28 20:34:52 2026 +0300 dpaa2-switch: fix handling of NAPI on the remove path [ Upstream commit e23d7c8c1d4ba435c457d7ffb2669175ec819b07 ] All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path. Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260528173452.1953102-6-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb177aa00c392de3dc530c34f173a962216f82dd 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 ee54f8d7e642c44cfcc2dcb390b4c50e145d81b8 Author: Ioana Ciornei Date: Thu May 28 20:34:49 2026 +0300 dpaa2-switch: fix the error path in dpaa2_switch_rx() [ Upstream commit 74c1c9f5c0c30bbd0c2cf87b6e3507e7ea46c13d ] In case of an error in dpaa2_switch_rx(), the dpaa2_switch_free_fd() function is called in order to free the FD. This is incorrect since the dpaa2_switch_free_fd() is intended to be used on Tx frame descriptors, meaning that it expects in the software annotation area of the FD data to find a valid skb pointer on which to call dev_kfree_skb(). Fix this by extracting the dma_unmap_page() from dpaa2_switch_build_linear_skb() directly into the dpaa2_switch_rx() function. This allows us to directly use free_pages() in case of an error before an SKB was created and kfree_skb() afterwards. Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260528173452.1953102-3-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e07ff2338f45adbf572850335d761c2f97545935 Author: Ioana Ciornei Date: Thu May 28 20:34:48 2026 +0300 dpaa2-switch: rework FDB management on the bridge leave path [ Upstream commit efc1d92eacf03afa6f4d53bf7120e059b6f961f2 ] On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge. Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260528173452.1953102-2-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 372bec8a01e2ab8eaa6851bdc346ede5f82dba99 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 c8f04a223b657c84fd22037f9d840af47432155b 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 0505f1e7bb5b981b6ed62d98b26ddce76142865d Author: Alessandro Schino <7991aleschino@gmail.com> Date: Mon May 11 20:15:15 2026 +0200 ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() [ Upstream commit aa1bdbb39f49c5bc9779316891c40005517842a5 ] The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path. Signed-off-by: Alessandro Schino <7991aleschino@gmail.com> Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 7feeb424bda7f6ffaf5090cdd01b300eaa74c02b Author: ZhengYuan Huang Date: Fri Apr 24 11:47:36 2026 +0800 fs/ntfs3: validate index entry key bounds [ Upstream commit 98d6e5d9dc1d34dcffc61549617581a5fe1ef807 ] [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them. Signed-off-by: ZhengYuan Huang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit f2d6bc89e2236939df189831707c8cdad199f57a Author: ZhengYuan Huang Date: Mon Apr 27 11:24:18 2026 +0800 fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [ Upstream commit b1c1101067d9536bcb0fe023b96ee2dde5535959 ] [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \#PF: supervisor instruction fetch in kernel mode \#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact. Signed-off-by: ZhengYuan Huang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 8b0cca98522bc2dda01169d6f17426a1b55ef15d 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 bd3a71103b320fe88621ac20fe316de0f8762347 Author: Jose Ignacio Tornos Martinez Date: Wed May 27 08:14:51 2026 +0200 net: wwan: t7xx: Add delay between MD and SAP suspend [ Upstream commit ae733795e593272f67d607c09d2a00637ac13ed0 ] SAP (Service Access Point) suspend occasionally times out with error -110 (ETIMEDOUT), followed by modem port errors and complete modem failure requiring a system reboot to recover. Error symptoms: mtk_t7xx 0000:72:00.0: [PM] SAP suspend error: -110 mtk_t7xx 0000:72:00.0: can't suspend (...returned -110) mtk_t7xx 0000:07:00.0: Failed to send skb: -22 mtk_t7xx 0000:07:00.0: Write error on MBIM port, -22 The modem firmware needs time after receiving the MD (modem) suspend request to complete internal operations before it is ready to accept the SAP suspend request. Without this delay, if runtime PM attempts to suspend while the firmware is busy, the SAP suspend command times out, leaving the modem in an unrecoverable state. Root cause and userspace interaction: ModemManager 1.24+ includes changes that reduce the likelihood of this issue by ensuring the modem is in a low-power state before the kernel attempts runtime suspend. However, the kernel driver should not depend on specific userspace behavior or ModemManager versions. Older versions (1.20-1.22) are still widely deployed, and the kernel should be robust regardless of userspace implementation details. There appears to be no hardware status register or other mechanism available to query whether the firmware is ready for SAP suspend. A delay between the two suspend requests is the most reliable solution found through testing. Add a 50ms delay between MD suspend and SAP suspend. This gives the firmware adequate time to complete internal operations without adding significant latency to the suspend path. This makes the driver robust across all ModemManager versions and system conditions. Testing: 96+ hours of continuous operation with ModemManager 1.20.2 and Fibocom FM350-GL modem. Zero SAP suspend timeouts observed across 2000+ successful suspend/resume cycles. Previously failed within 24 hours with 100% reproducibility. Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260527061451.12710-1-jtornosm@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c3515740174b778d0ee44acc477b51a6478da6b8 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 7d7dc59c369aed58e2342f85eec5e6d8617a32df Author: Chen Pei Date: Tue May 26 10:51:17 2026 +0800 ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach [ Upstream commit 3a59c3b772e5dc0cedecce8e7fbf7c2d6245b643 ] PCI root bridges enumerated by acpi_pci_root_add() can be the _DEP supplier for other ACPI consumers, most notably ACPI0017 CXL root devices whose probe path depends on acpi_pci_find_root() succeeding. Once the root bus has been added, those consumers can safely be enumerated, so notify them by clearing the dependency. Call acpi_dev_clear_dependencies() at the end of acpi_pci_root_add(), after pci_bus_add_devices(), following the same pattern used by other ACPI suppliers such as the EC (drivers/acpi/ec.c) and the ACPI PCI Link device (drivers/acpi/pci_link.c). The clear is intentionally done only on the success path; on the error paths the supplier did not attach and consumers must keep dep_unmet set. This is a prerequisite for honoring _DEP on ACPI0016 host bridges, which matters on architectures where the probe order of acpi_pci_root relative to cxl_acpi is not guaranteed (e.g. RISC-V). Signed-off-by: Chen Pei Suggested-by: Dan Williams (nvidia) Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260526025118.38935-2-cp0613@linux.alibaba.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ff0ab535f8febbd32afa5832f8d2d9b06a8d5060 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 19c947521e72032e34716898f1584e262f8e7583 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 6adf83f47b4c1b90adb35c8a2750180e5ca6664f Author: Srinivas Kandagatla Date: Thu May 28 19:58:01 2026 +0100 ASoC: qcom: q6apm: return error code to consumers on failures [ Upstream commit 3075ae5abbc370d2a9a01bd6d554a412d406f5bd ] Return errors from audioreach_set_media_format() to ensure callers are notified when media format setup fails. This could hide failures while programming media format parameters for individual modules and allow graph setup to continue with incomplete configuration. Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260528185806.6316-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 958cf3696ddc5ccafd3d0b8b0c03d90bcd771c0c Author: Miaoqing Pan Date: Tue May 12 10:23:50 2026 +0800 wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi [ Upstream commit 6b471e9aefee9ed73278eb1141e0d8530a56fae9 ] In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath11k_dp_rx_h_undecap_nwifi() function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially result in invalid data access and memory corruption. Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k] Call trace: ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k] ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k] ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k] ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k] ath11k_dp_service_srng+0x2e0/0x348 [ath11k] Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. This adapted from the discussion/patch of the ath12k driver [1]. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Link: https://lore.kernel.org/linux-wireless/20250211090302.4105141-1-tamizh.raja@oss.qualcomm.com/ # [1] Signed-off-by: Miaoqing Pan Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260512022351.2033155-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 141e4a142a79e66db00ad55b0bcd0c0f2c6b607d 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 c9fafb198deaf32b4cd62941d758be28f92d356e Author: Daniel Borkmann Date: Fri May 29 11:41:18 2026 +0200 libbpf: Also reset {insn,data}_cur on realloc failure [ Upstream commit d2f7bd066ed492aeaf82864fbf1f06770f9d9f9d ] realloc_insn_buf() as well as realloc_data_buf() free and NULL gen->insn_start / gen->data_start on -ENOMEM but leave gen->insn_cur / gen->data_cur pointing into the old, freed buffer. Just reset the cursors to NULL alongside the base pointers so the freed state is coherent. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529094119.307264-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a178c7030f2ddfa4753b88b7e168ba08cab1ce62 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 9ef0fd42dc866f1c915550ae67857c63fcb1d6c0 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 deda33b1c58caeda63c02b0a4cf4c8c35bedc518 Author: Miao Li Date: Mon May 4 11:04:06 2026 +0800 iio: light: stk3310: Deal with the ps interrupt issue in PM [ Upstream commit 9c1d639e90cf42f5c1401f91f38ffd89af6dd970 ] On the Inspur HS326 laptop(which integrated with HiSilicon M900 processor), if the STK3311-X chip's PS interrupt is configured in "Recommended interrupt mode", the interrupt cannot be triggered normally after waking from suspend or hibernation. In this case, neither disabling and re-enabling the interrupt nor resetting the PS threshold register can restore the interrupt to normal operation. If the interrupt is disabled in suspend() then reset the PS threshold register and enable the interrupt in resume(). This resolves the issue. Signed-off-by: Miao Li Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 6eca4f7135e6a971361cb6e0ae8a261aaff4d779 Author: Lad Prabhakar Date: Tue May 19 14:53:42 2026 +0100 mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC [ Upstream commit ebf7f2198ac4817bd2929cf83c697cefa8bf36a9 ] The RZ/G2E (R8A774C0) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2E is identical with the R-Car E3 (R8A77990), it requires the specific quirks and configuration defined in `of_r8a77990_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774c0" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2236b58447294083bd0900f19ac133763392464b Author: Karl Mehltretter Date: Mon May 25 19:04:28 2026 +0200 tracing: Disable KCOV instrumentation for trace_irqsoff.o [ Upstream commit 01046072880b654dbadf71be2f645aad4a7b5d87 ] When KCOV runs its boot selftest with whole-kernel instrumentation enabled, it sets current->kcov_mode to KCOV_MODE_TRACE_PC without installing a coverage area. Any instrumented code accepted as task-context coverage in that window dereferences current->kcov_area and crashes. On ARMv5 Versatile PB with CONFIG_KCOV_SELFTEST=y, CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y, boot hits a NULL pointer fault during the selftest: kcov: running self test Internal error: Oops: 5 [#1] ARM PC is at __sanitizer_cov_trace_pc+0x4c/0x90 Kernel panic - not syncing: Fatal exception A diagnostic run showed the unwanted coverage comes from the IRQs-off tracer callbacks reached from ARM IRQ entry before hardirq context is visible to KCOV: __sanitizer_cov_trace_pc from tracer_hardirqs_off+0x18/0x1cc tracer_hardirqs_off from trace_hardirqs_off+0x34/0x54 trace_hardirqs_off from __irq_svc+0x58/0xb0 __irq_svc from kcov_init+0x7c/0xdc and similarly through tracer_hardirqs_on(). trace_preemptirq.o is already excluded because this tracing path can run from early interrupt code and produce coverage unrelated to syscall inputs. Exclude trace_irqsoff.o as well, instead of requiring users to turn off CONFIG_KCOV_INSTRUMENT_ALL=y, which is the default whole-kernel KCOV mode. With the exclusion in place, the same ARMv5 Versatile PB QEMU test boots through the KCOV selftest and reaches userspace. Tested on ARMv5 Versatile PB QEMU with CONFIG_KCOV_SELFTEST=y, CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y. Link: https://patch.msgid.link/20260525170428.67211-1-kmehltretter@gmail.com Assisted-by: Codex:gpt-5 Signed-off-by: Karl Mehltretter Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 4f753121c14cfb7630092d91aad2a996f83ab081 Author: Lad Prabhakar Date: Tue May 19 14:53:41 2026 +0100 mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC [ Upstream commit 5ce500d31a1625d8fe7ede950201b8df076bdd48 ] The RZ/G2N (R8A774B1) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2N is identical with the R-Car M3-N (R8A77965), it requires the specific quirks and configuration defined in `of_r8a77965_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774b1" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit b48d313e3794a0fcc58a14a91583e7b2cee0f9b7 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 bc42f9eefd077209adfbea7099551ceac0165f1c 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 98bd034ed992f120a7ea9929a4ff3b0e8f53c582 Author: Charles Keepax Date: Wed May 20 17:36:31 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek devices [ Upstream commit 4dab2b904414fac53535c4e4cdad808132f4cdc2 ] Many systems ship with a Realtek audio codec in the ACPI that doesn't physically exist in the system. This confuses the newer function topology system that creates the soundcard, as it builds the card based on the ACPI information. Whilst we are working with the laptop vendors to try and stop this happening there are quite a few systems where this has shipped. Add a quirk to disable this "ghost" device. Currently this patch should cover: - Asus UX5406AA - Lenovo Yoga Pro 9i (83SF) - Lenovo Yoga Slim 7 Ultra (83QK) Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260520163631.3300102-4-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 14feb13e1211315579c78b37305059fc7413284b Author: Tiezhu Yang Date: Tue May 26 14:39:36 2026 +0800 libbpf: Add __NR_bpf definition for LoongArch [ Upstream commit a4a5d4ee061240a1d39053db0a87f841d43277c0 ] LoongArch uses the generic syscall table, where __NR_bpf is defined as 280 in include/uapi/asm-generic/unistd.h. To align with other architectures, add the __NR_bpf definition for LoongArch to avoid a potential compilation failure: "error __NR_bpf not defined. libbpf does not support your arch." This is a follow up patch of: commit b0c47807d31d ("bpf: Add sparc support to tools and samples.") commit bad1926dd2f6 ("bpf, s390: fix build for libbpf and selftest suite") commit ca31ca8247e2 ("tools/bpf: fix perf build error with uClibc (seen on ARC)") commit e32cb12ff52a ("bpf, mips: Fix build errors about __NR_bpf undeclared") Signed-off-by: Tiezhu Yang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260526063936.16769-1-yangtiezhu@loongson.cn Signed-off-by: Sasha Levin commit 3cdf18fa86a3572d280dcb31b5c6fe445ad4b271 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 4296cf86c946609becab4a2e473699bfbac00105 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 f1fa6c936fa9de80ae446ba5e76e227e991b8e56 Author: shayderrr Date: Sun May 17 12:04:56 2026 -0500 host1x: bus: Fix missing ops null check in error teardown [ Upstream commit 71d25f668bc5c0f36ea843462e12307dea45aaa3 ] In host1x_device_init(), the error teardown paths do not check client->ops before dereferencing it, unlike the forward init paths which correctly guard with 'client->ops &&'. This can result in a NULL pointer dereference if client->ops is NULL. Fix by adding the missing client->ops check in both the teardown and teardown_late labels. Signed-off-by: shayderrr Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260517170456.84927-1-darknessshayder@gmail.com Signed-off-by: Sasha Levin commit 8b59e2972b78a43b40964a1ba354e120bb5401e4 Author: Claudiu Beznea Date: Fri May 22 13:57:17 2026 +0300 pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP [ Upstream commit 01f94d53947df35ba77cdb3992a4e3ef9d9dc1ad ] The pinctrl and GPIO core code make exceptions for the -ENOTSUPP error code. One such example is gpio_set_config_with_argument_optional(), which returns success when gpio_set_config_with_argument() returns -ENOTSUPP, but reports failure for all other error codes. Returning -EOPNOTSUPP from the pinctrl driver on the unsupported pinctrl operation may lead to boot failures when pinctrl drivers implements struct gpio_chip::set_config, the system uses GPIO hogs, and the struct gpio_chip::set_config implementation returns -EOPNOTSUPP for the unsupported operations. Currently, the driver does not implement struct gpio_chip::set_config(). To avoid future failures, return -ENOTSUPP from rzv2m_pinctrl_pinconf_set(). rzv2m_pinctrl_pinconf_group_get() is used when dumping pinctrl configuration. pinconf_generic_dump_one(), which calls it, makes exceptions for the -EINVAL and -ENOTSUPP error codes. The documentation for struct pinconf_ops::pin_config_group_get states that it "should return -ENOTSUPP and -EINVAL using the same rules as pin_config_get()". The documentation for struct pinconf_ops::pin_config_get states: "get the config of a certain pin, if the requested config is not available on this controller this should return -ENOTSUPP and if it is available but disabled it should return -EINVAL". Return -ENOTSUPP for the unsupported pinctrl operation. Suggested-by: Geert Uytterhoeven Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260522105717.1727837-1-claudiu.beznea@kernel.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 28a9510e0368b3564b0f736261cf7c968171c2ee 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 4f03d84c95a51436878cd750a14f8ca37eeb3112 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 37c794f87a72471f7ef71633ac0550ad14ac0885 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 644888605f55395e6012ed43e3ed643ef7ab5013 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 8b7522d0073032beb5dc061c8b7f77779ac7f8b4 Author: ikaros Date: Wed May 27 20:06:25 2026 +0200 ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() [ Upstream commit 485829e6999b7909f50761a1c708660304edc945 ] Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to prevent buffer overflows. Link: https://github.com/acpica/acpica/commit/f85a43098d65 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2230782.OBFZWjSADL@rafael.j.wysocki Signed-off-by: Sasha Levin commit 90ebe7f8bb6ca1c6eadb16bed141ab8bb3dbab70 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 55594743fb6935d046cb6ce1e9f588828b43f3e9 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 e98825650c2eb1605c707fd1391ceed65bb8e481 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 9cfe3d13aa1436703ec338460c5cc275c20e4aa4 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 9010ad440f970e684324d507510415a67bc125e4 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 d239ccf5069f892cc36b9befafda030b3ca789e6 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 37e60db04eed9d6c5801d63f99cfd3af99b9a2c8 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 6509f56df51235fe447b624e40c098082717625c 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 2793b1c38f0053fd9b119ce4607dd056eb05d382 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 de2bbc8dbe7048f20f0a783a81e712fd3664de5b 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 5465786bf6876579a247a63bdebb8b637d9ea8d6 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 3a2eedb172e777f2c8608395eec42250fb355dae Author: Haoxiang Li Date: Mon May 25 16:26:11 2026 +0800 net: thunderx: fix PTP device ref leak in nicvf_probe() [ Upstream commit 2bcf59eefb9f00a2b1d426b639ee49c305a80695 ] cavium_ptp_get() acquires a reference to the PTP PCI device through pci_get_device(). If any initialization step fails after cavium_ptp_get(), the PTP PCI device reference is leaked. Add a common error path to release the PTP reference before returning from probe failures. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260525082611.61817-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4f7d2a8dc364c4e55d0a1533451339008512933f 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 45b927664041174935b51b6079271d2354eacb44 Author: Luka Gejak Date: Sat May 23 15:04:20 2026 +0200 net: hsr: require valid EOT supervision TLV [ Upstream commit 46d111a3ef3b5972804dcdce0833767143a12192 ] Supervision frames are only valid if terminated with a zero-length EOT TLV. The current check fails to reject non-EOT entries as the terminal TLV, potentially allowing malformed supervision traffic. Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT with a length of zero. Signed-off-by: Luka Gejak Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260523130420.62144-1-luka.gejak@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d09929654c8b0b15bb1e18b95cec72df63cf78d0 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 e79934064be85fc9a3a6434da857307d8b78e33d 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 10cd653ad47afa04b7fd9f33dee82dc7e8d79a47 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 2b2c0379121edb123d45bfb54848176cad84245b 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 4699adfdec35c81031df45b46e980f630844c6e5 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 e777ab46db8c2addffe801274d713252318ef750 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 bd8bc5431151e33191645d06883039211e0b9c07 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 68728593814ba8f7f252be10dc3c4beb2f1ed866 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 5197c2352b4b615225bbd45a2676963139ed5929 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 f05142d0eeaa6e8227511c88e10a2b8fe7a78fc4 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 63a043b38b38ce365df1cb4fe6423185c41f82df 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 506095856f85c2293b9163ec324583eae26a4ddd Author: Dian-Syuan Yang Date: Fri May 15 09:44:24 2026 +0800 wifi: rtw89: pci: enable LTR based on pcie control register [ Upstream commit 779bbe1902f29d0ef131249ddd42a8dfbe21d0fb ] Originally, driver always transmits LTR (Latency Tolerance Reporting) to pcie host, but it may cause pcie link down on some platforms because LTR is not supported. As a result, driver will check the control register of LTR setting to decide whether to enable LTR feature. This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the driver still issues LTR, the hardware has its own internal logic to determine whether to actually transmit it to pcie host. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260515014433.16168-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit 5d87473dd1be57eb368d43ab059c61d03988ea84 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 019ba0ef533d12dbb92aa56d783721e70fa48e7c 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 95d0b40c0623fd2b58c753f8dd6adda7263e3cd1 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 c08da4b5436aec900fb48e092b9d8897456d104d Author: Maoyi Xie Date: Thu May 21 14:54:28 2026 +0800 usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue [ Upstream commit e2ffaac1884b921b8ec2b3a964c6a8b5d610bf4b ] ast_udc_ep_dequeue() declares the loop cursor `req` outside the list_for_each_entry(). After the loop it tests `&req->req != _req` to decide whether the request was found. If the queue holds no match, `req` is past-the-end. It then aliases container_of(&ep->queue, struct ast_udc_request, queue) via offset cancellation. Whether that synthetic address equals `_req` depends on heap layout. The function can return 0 without dequeueing anything. Default `rc` to -EINVAL and set it to 0 only inside the match branch. `req` is no longer read after the loop, so the past-the-end dereference goes away. No extra cursor variable or post-loop test is needed. Suggested-by: Alan Stern Suggested-by: Andrew Jeffery Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260521065428.3261238-1-maoyixie.tju@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84e8a28661f9c0e342ee03f188aef8192317b8aa Author: Dave Carey Date: Fri May 15 10:19:40 2026 -0400 USB: cdc-acm: start bulk-IN polling when ALWAYS_POLL_CTRL is set [ Upstream commit e5ab27ddd74e2d67a94c51c6f2ad87b1ff13912b ] The INGENIC 17EF:6161 touchscreen composite device has a ~55-second watchdog that resets the USB device if the bulk-IN endpoint on the CDC data interface goes unread. The existing ALWAYS_POLL_CTRL quirk keeps the notification endpoint (ctrlurb / EP 0x82) polling continuously, but that alone is insufficient: the firmware monitors bulk-IN activity, not just notification-endpoint activity. Add acm_submit_read_urbs() calls to the two ALWAYS_POLL_CTRL paths that already restart the ctrlurb: 1. acm_probe(): start bulk reads at probe time alongside the ctrlurb, so the watchdog is satisfied from first bind without requiring a userspace process to open /dev/ttyACMn. 2. acm_port_shutdown(): restart bulk reads after port close alongside the ctrlurb restart, so the watchdog keeps running when the last TTY user closes the port. acm_read_bulk_callback() already resubmits each URB unconditionally on normal completion, so once submitted the reads remain active until an explicit kill (disconnect, suspend). acm_submit_read_urb() is a no-op for URBs that are already in flight (read_urbs_free bit clear), so the existing acm_port_activate() call remains correct and races are avoided. Tested on Lenovo Yoga Book 9 14IAH10 (83KJ): without this patch the device resets every ~55 s when no TTY is open; with it the device remains stable indefinitely. Signed-off-by: Dave Carey Link: https://patch.msgid.link/20260515141940.751397-1-carvsdriver@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 999ff3bf665f2abfb6af519ef3d6d42b061d3c15 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 936b08d87c667031725bcc753007e7c1182548c6 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 fd7d938ab4759a45eb107e658c199a2c47cc1ace 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 04e70574461604f97ab035022a8955d541065e96 Author: Nikhil Chatterjee Date: Sat Apr 25 20:18:19 2026 -0700 HID: bpf: Add Huion Inspiroy Frego M button quirk [ Upstream commit 857e71cb0a538b1660743a4267a1e789575f7966 ] The Huion Inspiroy Frego M pen report descriptor exposes the second side button as Secondary Tip Switch instead of Secondary Barrel Switch. This makes userspace see the control as the wrong pen button. Add a HID-BPF report descriptor fixup for the Bluetooth 256c:8251 device and USB 256c:2012 L610 variant. The fixup matches the expected pen descriptor and rewrites the offending usage from Secondary Tip Switch to Secondary Barrel Switch. Tested by building the HID-BPF object with: make -C drivers/hid/bpf/progs Huion__Inspiroy-Frego-M.bpf.o Signed-off-by: Nikhil Chatterjee Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit cebde6d88e34396c29f2f001d90e921677cc17d6 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 120e0db84a69f18e51ba9ae2d036df3a052a33e1 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 10f226687bcb07ed925a453b6f25e817165d113b 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 a0eaa3f4b6dcc829228752f6255f0e45cc94b273 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 c9f03e750d9ddf0f42c24e3ba683f26e377ffd72 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 65c2e9aab54f1caff8f573cf3294aed2db939d52 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 c6d069c34d57414c039167967ef826a8516c98f3 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 d05b0ee9b42cb3cc499272d1bc91609f7492a1a8 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 f99815e12bbbe1cdb1e5bbe1567e5953b8af422f 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 934a6381c79d815680c955d676791322e020bfda 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 07b5670610195afe9fb0b8cdd32404f0c1b30b60 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 ac0e823a228f94ad9d7a3d876cc07e59a7afb806 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 ced38b00e18eeeb96edab6602982a84c66ccc0e3 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 d394f54f0a77eee2bf95b4b8011af241ee536634 Author: Maurizio Lombardi Date: Thu May 14 10:32:53 2026 +0200 nvme-core: align fabrics_q teardown with admin_q in nvme_free_ctrl [ Upstream commit f702badaf7d31dc3dea6c66da92b5f35fadd89dc ] Currently, the final reference for the fabrics admin queue (fabrics_q) is dropped inside nvme_remove_admin_tag_set(). However, the primary admin queue (admin_q) defers dropping its final reference until nvme_free_ctrl(). Move the blk_put_queue() call for fabrics_q from nvme_remove_admin_tag_set() to nvme_free_ctrl(). This aligns the lifecycle management of both admin queues, ensuring they are freed symmetrically when the controller is finally torn down. Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Reviewed-by: Daniel Wagner Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 3d561a78db1e3ecbf390536ad8ce92f1413429b9 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 f27a5bda84ff3b0fea3de7572ff48e518e66cf5d 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 890a9c3bf9dae90dcabded9d8e10c708a13779f7 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 87a72e75f7560ea45cd28870194eaa153dd19e75 Author: Sudeep Holla Date: Sun May 17 20:02:42 2026 +0100 firmware: arm_scmi: Validate SENSOR_UPDATE payload size [ Upstream commit 32bc5496b48174dbca1f187f710955ee4d9527a1 ] SENSOR_UPDATE carries one or more sensor readings after the fixed notification header. The parser derives the expected reading count from the sensor description, but it did not verify that the received payload contains those entries before parsing them. Reject truncated update notifications before reading the variable array. Link: https://patch.msgid.link/20260517-scmi_fixes-v1-3-d86daec4defd@kernel.org Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit e63c0b63a28e0f9198ac4e85fdff0f0de373cfe8 Author: Pierre Barre Date: Tue May 12 13:20:31 2026 +0000 9p: use kvzalloc for readdir buffer [ Upstream commit b4d71bea144550ff4a0917f8c4b06d4063eb27a6 ] The readdir buffer is sized to msize, so kzalloc() can fail under fragmentation with a page allocation failure in v9fs_alloc_rdir_buf() / v9fs_dir_readdir_dotl(). The buffer is only a response sink and is never pack_sg_list()'d, so kvzalloc() is safe for all transports, unlike the fcall buffers fixed in e21d451a82f3 ("9p: Use kvmalloc for message buffers on supported transports"). Signed-off-by: Pierre Barre Message-ID: <20260512132032.369281-1-pierre@barre.sh> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit aef2819d67a1b231daa39a752cb43edc86c6bb3a 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 ad8b42dc6fde936244a594a2dbe21e3d8e6f1d20 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 fe91068a1900f017b4d3068b39de613c7fbb632d 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 7e06636260a2d95e3fa181bc337d0eeb812b7a41 Author: David Francis Date: Tue May 12 15:15:33 2026 -0400 drm/amdkfd: Check bounds on allocate_doorbell [ Upstream commit 1f087bb8cf9e8797633da35c85435e557ef74d06 ] allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS. Signed-off-by: David Francis Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 41460d2dd0246f0ab7e80b103d34c8649e022999 Author: David Francis Date: Tue May 12 15:18:18 2026 -0400 drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id [ Upstream commit bfe9a7545b2a7be1c543f1741e16f2d5ec4116ae ] allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues. Signed-off-by: David Francis Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0fa79c5cfe939ab3275656deed00582ba18e7a32 Author: Bjorn Helgaas Date: Mon May 18 14:12:19 2026 -0500 PCI: Wait for device readiness after D3hot -> D0uninitialized transition [ Upstream commit 41167a1e98536b4baf0846fd259c8124bd1c4e1b ] For a device that advertises No_Soft_Reset == 0, a transition from D3hot to D0uninitialized is a soft reset, and the resulting internal device state is undefined. Per PCIe r7.0, sec 2.3.1, a transition from D3hot to D0uninitialized mandates a minimum 10 ms delay before accessing the device. Following this delay, the device is permitted to respond to initial configuration requests with a Request Retry Status (RRS) completion status if it needs more time to initialize. Call pci_dev_wait() after pci_power_up() performs a D3hot->D0uninitialized transition to ensure the device is ready to accept config accesses, as is done after the similar transition in pci_pm_reset(). If the device is already ready, this is essentially a no-op except for one additional config read. Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki (Intel) Link: https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com Signed-off-by: Sasha Levin commit bde89a408974e1450b0d2362c6c2b9c193765bdc 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 47adcac36fcb5ae53e18b3bfce39f66dd06feba3 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 145b053e6b25f0d41a988dfed25758752902f616 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 d6169b47f1e25fa42bbccc1a8c459c2bb3185fc3 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 a04db06aa26b3fc5aff5258c8875efcd9c9ea9e3 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 630b83001e434e7c2969aca91c38c296b597705d 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 96cac217e909607fb4080618d4adb2ed33997be8 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 3ee663bd801826a3a2505020adf2e839b637a1c8 Author: Alexey Klimov Date: Thu Apr 30 12:53:27 2026 +0100 clk: samsung: exynos850: mark APM I3C clocks as critical [ Upstream commit 44984aaf1aa727ff944dd4b72fcf069d08b0056d ] The Exynos850 APM co-processor relies on the I3C bus to communicate with the PMIC. Currently, there is no dedicated PMIC consumer driver managing these clocks, so the clock subsystem automatically gates them during the initialisation. Once gated, any subsequent ACPM communication with APM results in timeouts. As a temporary workaround (and let's hope it doesn't become permanent), mark both `gout_i3c_pclk` and `gout_i3c_sclk` as CLK_IS_CRITICAL ones to prevent the clock subsystem from disabling them. This makes the ACPM communication functional. This workaround should be reverted once a proper ACPM PMIC driver is implemented to manage these clocks. Cc: Sam Protsenko Cc: Tudor Ambarus Signed-off-by: Alexey Klimov Reviewed-by: Sam Protsenko Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20260430-exynos850-i3c-criticalclocks-v1-1-6e1fd8dfa21b@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 08d6ccc9c1aab82660f2876ce45a6efac0b70d96 Author: Stefan Berger Date: Thu Apr 16 11:40:36 2026 -0400 integrity: Check for NULL returned by asymmetric_key_public_key [ Upstream commit c93a5f038ccc11ed8558ce642f62d5ede701a348 ] Check for a NULL pointer returned by asymmetric_key_public_key and return -ENOKEY in this case. Signed-off-by: Stefan Berger Tested-by: Kamlesh Kumar Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit c52af3d8fb003c6023b39fdfbdf6b9725c557749 Author: Mieczyslaw Nalewaj Date: Sat May 9 14:10:29 2026 +0200 net: dsa: realtek: rtl8365mb: add support for RTL8367SB [ Upstream commit 28702a215c96917d85558ad6309a57ab224808c0 ] Add chip info entry for the Realtek RTL8367SB switch. This device has chip ID 0x6367 and version 0x0010. It exposes two external interfaces: port 6 supports MII, TMII, RMII, RGMII, SGMII and HSGMII, while port 7 supports MII, TMII, RMII and RGMII. Use the existing 8365MB-VC jam table for initialization. Reviewed-by: Luiz Angelo Daros de Luca Signed-off-by: Mieczyslaw Nalewaj Link: https://patch.msgid.link/3c6d822b-0e85-4173-86ba-2badb140bbf1@yahoo.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97adc8cd04df2085f7fd437838005f3bb16bafae Author: Arash Golgol Date: Sat May 9 19:40:13 2026 +0330 media: video-i2c: use vb2_video_unregister_device on driver removal [ Upstream commit 56384b486b80ce4a2bc93689aae49995f908f90d ] The driver uses vb2_fop_release() as its file release operation, so vb2_video_unregister_device() should be used instead of video_unregister_device() during driver removal. This ensures that the vb2 queue is properly disconnected before the video device is unregistered. Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 651687a3e35d0c25cf1cacab72b1e21f09ede29f Author: Sophie D Date: Fri May 8 22:54:05 2026 -0400 drm/gud: Add RCade Display Adapter VID/PID pair [ Upstream commit ac5ac0acf11df04295eb1811066097b7022d6c7f ] The RCade Display Adapter is a hardware device that allows driving an Arcade CRT display via the GUD protocol. Currently it spoofs an existing GUD VID/PID pair. However, now that it has its own pair assigned, it makes sense to add this to the list of pairs that GUD supports natively. More information can be found in the project repositories: https://gitlab.scd31.com/stephen/stm32-usb-vga-adapter-hardware https://gitlab.scd31.com/stephen/stm32-usb-vga-rcade-adapter Link: https://pid.codes/1209/4FB3/ Signed-off-by: Sophie D Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260509025405.4143956-1-patches@scd31.com Signed-off-by: Sasha Levin commit 662ba173a41cedf2315fa9a307af832d60f0fc64 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 0d51d4e2edfa534ca520a3b563ad2fb6de1ccb53 Author: Florian Eckert Date: Fri Apr 17 10:35:48 2026 +0200 PCI: intel-gw: Enable clock before PHY init [ Upstream commit febf9ed3c35e5eec7ea384ebbd55a5296e3ca5e9 ] To ensure that the boot sequence is correct, the DWC PCIe core clock must be switched on before PHY init call [1]. This changes are based on patched kernel sources of the MaxLinear SDK. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de Signed-off-by: Sasha Levin commit ee343385cbd3e2b3355ee510dc8b93da95ea7cfe 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 a0cde8d70d64c1a75fbd57f01d9f2d7cccac8319 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 c465608bd25d7f8565be7817a6a36a5d69f8aa14 Author: Shawn Lin Date: Thu Apr 9 15:48:11 2026 +0800 mmc: core: Add validation for host-provided max_segs [ Upstream commit 3e0483e93a8be320f70a1ff68d835f7f015af311 ] The max_segs field is of type unsigned short, and if a host driver sets an excessively large value, it may be truncated to zero. This can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size allocation request, which leads to undefined behavior. Under the SLUB allocator, kmalloc(0) returns a special pointer (ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to true, and sg_init_table() will then attempt to access invalid memory, resulting in a crash: dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133 mmc1: new UHS-I speed SDR104 SDHC card at address aaaa Unable to handle kernel paging request at virtual address 0000001ffffffff0 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000 [0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT Hardware name: Rockchip RK3576 EVB V10 Board (DT) Workqueue: events_freezable mmc_rescan pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sg_init_table+0x2c/0x50 lr : sg_init_table+0x24/0x50 sp : ffff8000837db710 x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300 x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000 x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010 x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000 x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00 x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010 Call trace: sg_init_table+0x2c/0x50 (P) mmc_mq_init_request+0x64/0x90 blk_mq_alloc_map_and_rqs+0x3ac/0x480 blk_mq_alloc_set_map_and_rqs+0x98/0x1e0 blk_mq_alloc_tag_set+0x1c0/0x290 mmc_init_queue+0x120/0x370 mmc_blk_alloc_req+0x150/0x420 To prevent this, add a validation check in mmc_mq_init_request() to detect when sg_len (derived from max_segs) is zero. If sg_len is zero, we return an error and print an error message, allowing host driver developers to identify and fix incorrect max_segs configuration. This is a defensive measure that ensures the MMC core fails gracefully when host drivers provide invalid max_segs values, rather than crashing with a page fault. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9e27ec0029475d9c0652157a1c2d936c23c0db2c 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 c6eb5247d1e88cf5ac5f7505cae1f925ca30bcb9 Author: Parth Pancholi Date: Wed Mar 11 09:48:13 2026 +0200 drm/bridge: tc358768: Set pre_enable_prev_first for reverse order [ Upstream commit 6b2bb5438bcfd7bad868665cd2aed1caf9ba3f2b ] Enable the pre_enable_prev_first flag on the tc358768 bridge to reverse the pre-enable order, calling bridge pre_enable before panel prepare. This ensures the bridge is ready before sending panel init commands in the case of panels sending init commands in panel prepare function. Signed-off-by: Parth Pancholi Tested-by: João Paulo Gonçalves # Toradex Verdin AM62 Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260311-tc358768-v2-2-e75a99131bd5@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 937778426461e0bd08029cb019982034bacd5c12 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 4918b0bd7d2baafb45d87dca9e322137c96005c2 Author: Ruoyu Wang Date: Thu Apr 23 19:19:56 2026 +0800 crypto: ixp4xx - fix buffer chain unwind on allocation failure [ Upstream commit 25056329384010a8672552b134f609601dc4f80e ] chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly. Signed-off-by: Ruoyu Wang Acked-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3ac9400589233e2d060e5aa6e9019005e7ac889b 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 46824c7423d632bbf4f90129b0c7c843b019c867 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 cf2d760e4c948f7c3eddb363a3d88489d1181d6d Author: Marek Behún Date: Mon May 4 17:32:25 2026 +0200 net: dsa: mv88e6xxx: define .pot_clear() for 6321 [ Upstream commit 17826d9708a57d27011d0a6efdebb628d6f8299a ] Commit 9e907d739cc3 ("net: dsa: mv88e6xxx: add POT operation") did not add the .pot_clear() method to the 6321 switch operations structure. Add them now. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260504153227.1390546-4-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 325396b3ad52b28db1e89a02c82874d99c0ca4b7 Author: Ben Reed Date: Tue May 5 10:16:33 2026 -0600 PCI: switchtec: Add Gen6 Device IDs [ Upstream commit 5e6c21c56998e1e58d2f314e70779989ea0fee5d ] Add device IDs for the next generation of switchtec products. No changes to the driver were required with the new version of the hardware. [logang: rewrote commit message] Signed-off-by: Ben Reed Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260505161633.67454-1-logang@deltatee.com Signed-off-by: Sasha Levin commit 4b6092cc0ab5f39e47d98f97f16cbd1888d0af38 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 3ff12d5ea9cb0d0fd89c24b69940f0b989bf6d2a 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 41af2fc137d333872f15be4abb085dbafa01c969 Author: Alan Borzeszkowski Date: Thu Oct 2 15:37:22 2025 +0300 thunderbolt: Don't create multiple DMA tunnels on firmware connection manager [ Upstream commit cf0c38ee554c3e9062408cc3a38325483d52ecd0 ] Firmware connection manager supports only one DMA tunnel per XDomain connection. Firmware prior Intel Titan Ridge failed the operation directly but the same does not happen anymore on Titan Ridge and forward. For this reason add an explicit check, and fail the operation accordingly in the driver. Signed-off-by: Alan Borzeszkowski Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 54ad3415cc211ca0d64ae1bf3234d6eb5c6aedd0 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 e8656465d08ed832e120c9cca4a6d0c8ccb45698 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 cca72fe513f3d6b1279fe83483f8a8990adbe0c6 Author: Mika Westerberg Date: Mon Sep 8 13:31:29 2025 +0300 thunderbolt: Keep XDomain reference during the lifetime of a service [ Upstream commit 8b4060998637f06975fceee9b73845d8672d411e ] This is needed because we release the service ID in tb_service_release() and the ID array is owned by the parent XDomain. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 000189b249e45e63ee873d0c59c3be1805349681 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 1885308fc441f1d32b97029778f20268fb050109 Author: Vineeth Vijayan Date: Tue Apr 28 10:43:41 2026 +0200 s390/cio: Purge based on the cdev's online status [ Upstream commit 58d50cad63e85daae032924ecc3d457fb1ec02fb ] Ensure that all devices currently offline are purged correctly. Previously, purging logic relied on the internal FSM state to determine whether a device was offline. However, devices with a target state of offline could be skipped if CIO internal processing was still ongoing during the purge operation. Update the purge decision logic to rely on the online variable in the cdev structure instead of the internal FSM state, providing a more reliable indication of actual device availability. Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit be487f0026e6499184176c90f2531b8be07ebc56 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 98fda9385a0cd6248012ad08a00c7b10728ef2e7 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 91c44b2d1552d20da3ffbe98eed066fe336d39d8 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 c59dfa1a5e4ec267252707063b8b15ad02c7838e Author: Siew Chin Lim Date: Mon Sep 6 09:46:21 2021 +0800 firmware: stratix10-svc: change get provision data to async SMC call [ Upstream commit 4b0a32016347bfd6ae9849f21b1b767905f68d14 ] Change INTEL_SIP_SMC_FCS_GET_PROVISION_DATA's SMC call to async from sync to avoid long runtime which may cause the watchdog timeout issue. Signed-off-by: Richard Gong Signed-off-by: Siew Chin Lim Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit c55b6450f75f428823e2b19d631b63889822b314 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 a8cdb18ef80d67790d8611ba94ae3d81901c9e04 Author: Panagiotis Petrakopoulos Date: Wed Apr 15 08:29:59 2026 +0300 wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result() [ Upstream commit d5e6f353ce1e1c25b8458ea390ed09d2377412c5 ] It was recently reported that rtw_fw_adaptivity_result() in fw.c dereferences rtwdev->chip->edcca_th without a NULL check. The issue is that devices with the 8821CE chip don't define edcca_th in their chip info. As a result, when rtw_fw_adaptivity_result() tries to dereference it, the kernel triggers an oops. Add a NULL check for edcca_th before dereferencing it in rtw_fw_adaptivity_result() in fw.c. Placing the check at the function entry avoids logging any garbage values. This change does not address the root cause for this behavior, but it prevents the NULL dereference and the resulting oops while a more permanent solution is developed. Tested on a 8822CE chip which defines edcca_th, so this issue is not present on it, but it still uses this driver and I can verify there are no regressions. Suggested-by: Ping-Ke Shih Reported-by: Oleksandr Havrylov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286 Signed-off-by: Panagiotis Petrakopoulos Acked-by: Ping-Ke Shih Tested-by: Oleksandr Havrylov Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260415052959.14844-1-npetrakopoulos2003@gmail.com Signed-off-by: Sasha Levin commit 19f26fd1f9c8161a83ab26d5bf688e40408f9999 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 6e24f72985782013bf2feb0f0712b2ac9390e909 Author: Johannes Berg Date: Wed Apr 15 14:42:12 2026 +0200 wifi: nl80211: reject beacons with bad HE operation [ Upstream commit 8b9a100e1a76c52988b31099b349fd95a58c8768 ] The HE operation element not only needs to be longer than the fixed part, but also have an appropriate size for the variable part inside of it. Check this. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.6217f5974fb5.Iff7ff6bcb159584e756d0f825c65860cdd53c6ea@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 17a73b5e2a838a95e491bcc4c7282478f9782fed 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 b774e2998c9d2da5e0dbd147b76b64fdbff0c285 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 2c30c5419dc84506a54d7e43f5e81eca6409de1a 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 366b3959dca0d11f5f722ceaa207e11c24822729 Author: Xu Yang Date: Thu Apr 23 17:53:55 2026 +0800 usb: gadget: udc: skip pullup() if already connected [ Upstream commit 62911bc82b0332aee7546156800d3516500fa1e1 ] The device controller may update vbus status via usb_udc_vbus_handler(), which tries to connect the gadget even though gadget_bind_driver() has already called usb_udc_connect_control_locked(). This causes pullup() to be called twice. Avoid this by checking if gadget->connected is true. This also set gadget->connected as false in usb_gadget_activate() if it became connected while it was being deactivated. Otherwise, usb_gadget_connect_locked will return early and pullup() won't be called. Signed-off-by: Xu Yang Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260423095355.2673035-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c6988714c0549e06610635c7a71e88635da6db64 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 0fcf01c9cb41c1857468371cb17f5b8b40b83a63 Author: Cássio Gabriel Date: Sun Apr 19 17:30:29 2026 -0300 ALSA: usb-audio: Propagate write errors in generic mixer put callbacks [ Upstream commit 87a6f2fa6e6c69bb649fa327635a0bd977724603 ] mixer_ctl_feature_put(), mixer_ctl_procunit_put(), and mixer_ctl_selector_put() ignore failures from their SET_CUR helper routines and report the control as changed whenever the requested value differs from the current one. If the device rejects the write, userspace still sees success although the hardware state did not change. Propagate write failures instead, using filter_error() so ignore_ctl_error keeps the same semantics as the existing get paths. Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-1-5a3bd4a673ae@gmail.com Signed-off-by: Sasha Levin commit 0de4243e13234dc25a1ceb9a837c49d1db36f24a Author: Ioana Ciornei Date: Wed Apr 1 17:45:08 2026 +0300 bus: fsl-mc: wait for the MC firmware to complete its boot [ Upstream commit 208858b1b48eba83d073542372329cf8ed606526 ] There are use cases in which the Management Complex firmware boot process is started by the bootloader which does not wait for the boot to complete. This is mainly done in order to reduce the overall boot time of a DPAA2 based SoC. In this kind of circumstance, the fsl-mc bus driver needs to make sure that the MC firmware boot process is finished before proceeding to the usual operations such as interrogating the firmware to gather all existent DPAA2 objects, creating the fsl-mc devices on the bus etc. Add this kind of check early in the boot process of the fsl-mc bus and defer the probe in case the firmware is still in its boot process. Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20260401144508.3062019-1-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit f2e045fc9b37c2d647837276f3c91f1373612725 Author: Boris Brezillon Date: Wed Apr 1 15:48:45 2026 +0200 drm/gem: Consider GEM object reclaimable if shrinking fails [ Upstream commit 71c8224a18825102ee1e5e70498f96f6c2d2a81d ] If the object wasn't moved to a different LRU after the shrink callback returns, it means the buffer is still reclaimable. Update the remaining counter to reflect that. v2: - Collect R-b v3: - Collect R-b v4: - No changes v5: - No changes v6: - No changes v7: - No changes Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20260401134854.2275433-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin