commit 782e1ccebdad2ae5cdfc583cf1725d0c20e08e54 Author: Alexandre Frade Date: Thu Aug 27 15:56:59 2026 +0000 Linux 6.18.47-rt-xanmod1 Signed-off-by: Alexandre Frade commit 48fc777af8304fd0e6ffca0931476d883ef3083b Merge: da3165ece5d7 b260538251f0 Author: Alexandre Frade Date: Thu Aug 27 15:54:24 2026 +0000 Merge branch '6.18' into 6.18-rt commit b260538251f03dd172a267b0d10c9ad04d4fd5a9 Author: Alexandre Frade Date: Thu Aug 27 15:42:03 2026 +0000 Linux 6.18.47-xanmod1 Signed-off-by: Alexandre Frade commit 3cefea4ac89fced51f6100a1e5491200ab795d68 Merge: d3fea146457b 7519e95095c9 Author: Alexandre Frade Date: Thu Aug 27 15:40:54 2026 +0000 Merge tag 'v6.18.47' into 6.18 This is the 6.18.47 stable release commit 7519e95095c9b83bc9ed9f6eff723801fe9a4387 Author: Greg Kroah-Hartman Date: Thu Aug 27 14:32:55 2026 +0200 Linux 6.18.47 Link: https://lore.kernel.org/r/20260825132541.887883084@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman commit 3ce832e2bd431d0c12ba525ed73ad8fbc4191da5 Author: Eric Dumazet Date: Thu Aug 27 06:08:01 2026 +0000 net: gro: properly validate BIG TCP aggregation criteria When GRO attempts to aggregate packets beyond GRO_LEGACY_MAX_SIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header). However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skb_gro_receive(), leading to several issues: 1. skb_gro_receive() checked skb_headroom(p) instead of the actual space before the MAC header (p->mac_header). Because skb_headroom(p) includes mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check with p->mac_header < 8 bytes. When ipv6_gro_complete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->mac_header. 2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q / ETH_P_8021AD) to aggregate beyond 64KB because p->protocol != ETH_P_IPV6 was true. 3. It checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB. Fix skb_gro_receive() to strictly enforce: - NAPI_GRO_CB(skb)->proto == IPPROTO_TCP - Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation) - Protocol must be either ETH_P_IP or ETH_P_IPV6 - If ETH_P_IPV6, p->mac_header must be at least sizeof(struct hop_jumbo_hdr) Returning -E2BIG from skb_gro_receive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping. This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y. Fixes: 0fe79f28bfaf ("net: allow gro_max_size to exceed 65536") Fixes: b1a78b9b9886 ("net: add support for ipv4 big tcp") Reported-by: Sam Dlinn Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Signed-off-by: Greg Kroah-Hartman commit 5b4f2bec7bea6c04084d720d731bedee7caf878d Author: Abdifatah Suruur Date: Thu Aug 13 20:47:07 2026 +0300 ptp: vmclock: prevent read-only mappings from becoming writable commit a5edadbae57e2298a56cf7a4e774a027905a331f upstream. vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071). Cc: stable@vger.kernel.org Fixes: 205032724226 ("ptp: Add support for the AMZNC10C 'vmclock' device") Signed-off-by: Abdifatah Suruur Link: https://patch.msgid.link/20260813174707.14809-1-suruurism@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dba60d26e9dda3e157ad6b0934d4232f6c6904ee Author: Felix Hoffmann Date: Tue Aug 25 11:33:13 2026 -0400 futex: Avoid private hash use-after-free on final put [ Upstream commit 1c7efabfbaf796f11000a46094a69955a01ec6cc ] futex_private_hash_put() drops the reference to fph before evaluating fph->mm for wake_up_var(). futex_ref_put() enables preemption again before returning. If that put drops the final reference and the task is preempted, another task can pivot to the replacement hash and free the old hash after an RCU grace period. The first task then reads fph->mm from the freed allocation when it resumes. KASAN reports a slab-use-after-free in futex_private_hash_put(), with the read at offset 24 in a freed kmalloc-512 allocation. The allocation and free stacks point to futex_hash_allocate() and the RCU free path, respectively. Load the mm pointer while the fph reference is still held and pass the saved value to wake_up_var(). wake_up_var() uses the pointer as a waitqueue key and does not dereference the mm through it. Fixes: bd54df5ea7ca ("futex: Allow to resize the private local hash") Signed-off-by: Felix Hoffmann Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260731155024.1150011-1-f3lix.dev@gmx.de [ dropped the `!fph` NULL guard since this tree's callers already check, keeping the existing `if (futex_ref_put(fph))` form ] Signed-off-by: Sasha Levin commit e1534d49a7b8ba728e84b020f6d802aa1cb759d9 Author: Laxman Acharya Padhya Date: Thu Jul 30 18:05:28 2026 +0545 Bluetooth: hci_aml: validate firmware segment lengths commit 2bf6b9baca9372ea51b6d0f2820dc9bf29a83ef4 upstream. aml_download_firmware() reads two lengths from the firmware header and uses them to build pointers before checking that the header and segment data are present. A truncated or inconsistent firmware image can make the driver read past firmware->data while constructing TCI commands. Reject images shorter than the header and ensure that the ICCM and DCCM ranges fit within the loaded firmware before downloading either segment. Fixes: 37bac77e4649 ("Bluetooth: hci_uart: Add support for Amlogic HCI UART") Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit b7d9edcf9fe6e9ec3a2e80ef9e8d44ef9b4f2894 Author: Ali Ahmet Memis Date: Thu Aug 6 17:39:53 2026 +0000 Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255 commit 5d95286b6d6e8f1d304da7522bfa6860fc017e48 upstream. mgmt_hci_cmd_sync() checks that the message length agrees with params_len but puts no upper bound on it. params_len is __le16 while the parameter length in the HCI command header is a u8: struct hci_command_hdr { __le16 opcode; __u8 plen; } __packed; hci_cmd_sync_alloc() assigns one to the other: hdr->plen = plen; if (plen) skb_put_data(skb, param, plen); so a params_len of 256 leaves plen at 0 while all 256 bytes are still appended. The frame handed to the driver then declares no parameters and carries 256 of them. On a length framed transport such as H:4 the controller takes the trailing bytes as the start of the next packet. The mgmt socket MTU is HCI_MAX_FRAME_SIZE, so params_len can reach about 1KB this way. Commit 03f1700b9b4d ("Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commands") only made params_len agree with the message length, a value that fits the message but not the header field is still accepted. Reject params_len that does not fit the header field. Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1f6d1f2611af0eb36b133a41d29ffd2cc2601615 Author: Ali Ahmet Memis Date: Thu Aug 6 23:06:21 2026 +0000 Bluetooth: ISO: zero the sockaddr before returning it in getname commit 884cf2cc957da7ac178a0e6c6c69ddfec0481cc8 upstream. iso_sock_getname() fills a struct sockaddr_iso in place and returns its size without clearing it first, so bytes it does not write are copied to user space from the kernel stack. The getsockname(2) and getpeername(2) paths both run through do_getsockname(), which hands getname() an uninitialized sockaddr_storage on the stack and copies back up to the number of bytes getname() returns, so the driver has to initialize every byte it accounts for. Two ranges are left uninitialized: - struct sockaddr_iso is 10 bytes but only 9 are written (family, iso_bdaddr, iso_bdaddr_type), leaking the trailing pad byte on every call. - for a broadcast peer (BIS_LINK or PA_LINK) the returned length grows by sizeof(struct sockaddr_iso_bc), but only bc_sid, bc_num_bis and bc_bis are filled; bc_bdaddr and bc_bdaddr_type, the first 7 bytes of that structure, are never written. An unprivileged process can open a BTPROTO_ISO socket and reach the pad leak with getsockname(); the broadcast leak needs an established BIS/PA connection. l2cap and rfcomm already memset their sockaddr in getname for the same reason; do the same here. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Fixes: 0a766a0affb5 ("Bluetooth: ISO: Fix getpeername not returning sockaddr_iso_bc fields") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 753af97d8d42377625cbff0e59031159adbabc56 Author: Ali Ahmet Memis Date: Fri Aug 7 00:59:55 2026 +0000 Bluetooth: ISO: do not force BT_LISTEN after a failed BIG sync commit 9838a80096ba472d5e03057136a112631aabae6e upstream. iso_sock_recvmsg() handles the deferred setup of a broadcast sink by dropping the socket lock, calling iso_conn_big_sync() and taking the lock again: release_sock(sk); iso_conn_big_sync(sk); lock_sock(sk); sk->sk_state = BT_LISTEN; The state is written unconditionally, but iso_conn_big_sync() returns void and has paths that do nothing at all: hci_get_route() may fail, and after re-acquiring the socket lock the connection may already be gone, in which case it bails out without ever issuing an LE BIG Create Sync. While the lock is dropped the connection can be torn down, for example when the controller reports HCI_EV_LE_PA_SYNC_LOST: hci_le_pa_sync_lost_evt() hci_disconn_cfm() -> iso_disconn_cfm() -> iso_conn_del() iso_chan_del() iso_pi(sk)->conn = NULL sk->sk_state = BT_CLOSED sock_set_flag(sk, SOCK_ZAPPED) iso_conn_big_sync() then finds conn == NULL and returns, but the caller still overwrites the BT_CLOSED that iso_chan_del() has just set. The socket ends up marked BT_LISTEN with no connection, so recvmsg() reports success for a setup that never happened and a later accept() waits for BIS connections that can never arrive instead of failing. A concurrent shutdown() reaches the same write by another route: __iso_sock_close() takes the BT_CONNECT2 PA sync path to iso_sock_disconn(), which sets BT_DISCONN but leaves conn and conn->hcon in place, so iso_conn_big_sync() succeeds and BT_LISTEN is written over BT_DISCONN. Both the BT_CONNECT2 and the BT_CONNECTED case write the state the same way. Let iso_conn_big_sync() report whether the BIG sync was started, and only move the socket to BT_LISTEN when it was and when the state has not changed while the lock was dropped, mirroring what the BT_CONNECT case of the same switch already does with iso_connect_cis(). Both conditions are needed, the error alone does not cover the shutdown() race. This corrupts the socket state machine only, it is not a memory safety issue. KASAN and lockdep stayed quiet in all of the runs below. Reproduced with an emulated controller over /dev/vhci on a KASAN + PROVE_LOCKING kernel. A PA sync broadcast sink socket is driven to BT_CONNECT2 and recvmsg() on it is raced against teardown, with a debug delay inside the lock-dropped section to widen the window: - HCI_EV_LE_PA_SYNC_LOST injected: 64 of 64 rounds left the socket in BT_LISTEN with the connection gone, recvmsg() returned 0 and accept() on that fd returned EAGAIN, which iso_sock_accept() can only do while the socket is BT_LISTEN. With this patch, 0 of 64, recvmsg() returns an error and accept() returns EBADFD. - shutdown() instead of a controller event: 24 of 32 rounds wedged in BT_LISTEN, 0 of 32 with this patch. With only the error check in place and a short window, one round still wedged while recvmsg() returned 0, which is the case the state re-check covers. An unraced control round behaves the same before and after: recvmsg() returns 0, the socket reaches BT_LISTEN and an LE BIG Create Sync is issued. Fixes: 7a17308c1788 ("Bluetooth: iso: Fix circular lock in iso_conn_big_sync") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit fe93a697a7a92fa9adf78c9ff67a10db3193290c Author: Chengfeng Ye Date: Sat Aug 1 15:05:24 2026 +0800 Bluetooth: hci_sync: Fix accept list UAF during suspend commit f57b399c4fa1501b2d5451f52d861ece86bcf3db upstream. hci_update_event_filter_sync() walks hdev->accept_list while sending a synchronous HCI command for each remote-wakeup device. The suspend path holds hdev->req_lock, but accept-list updates are serialized by hdev->lock. Consequently, remove_device() can free the current list entry during the controller wait. The following interleaving causes the use-after-free: hci_update_event_filter_sync() remove_device() fetch accept-list entry hci_set_event_filter_sync() wait for controller response hci_dev_lock() list_del() kfree() hci_dev_unlock() read the freed list.next KASAN reported: BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910 Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10 Workqueue: events vhci_suspend_work Call Trace: hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10 Allocated by task 86: hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 91: kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0 Snapshot the remote-wakeup addresses under hdev->lock. Release the lock before sending HCI commands. Clear the controller event filter before building the snapshot, and skip allocation and the second list traversal when there are no matching entries. This preserves the original filter and scan-state updates without retaining an accept-list node across a controller wait. Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-bluetooth/20260730092331.2069741-1-nicoyip.dev@gmail.com/ Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit e3f82e8f2a5915f533b57a065e9a045aa2ee03bc Author: Laxman Acharya Padhya Date: Sat Aug 1 23:54:52 2026 +0545 Bluetooth: hci_event: validate LE Set CIG Parameters response commit 0acd4eeb4b225b9bebbf9ef96cc10cdd79b94899 upstream. The Command Complete dispatch validates only the fixed part of the LE Set CIG Parameters response. After that part is pulled from the skb, hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the trailing handle array. Matching num_handles against the command's num_cis does not guarantee that the response contains the advertised handles. A truncated response from a malfunctioning controller can therefore make the handler read beyond the skb data. Validate that the remaining skb data contains all advertised handles. Include this in the existing response validation so malformed responses also follow the established CIG failure handling. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 39a3afb91be3cb465f46ce7a8e5696d9e33edf93 Author: Chengfeng Ye Date: Thu Jul 30 16:32:02 2026 +0800 Bluetooth: hci_event: fix LE list UAF on reset commit 33af47e847fe4a28b109673affb5874015d54f5a upstream. hci_cc_reset() clears the LE accept and resolving lists without taking hdev->lock. Other command-complete handlers serialize updates to these lists with that lock, and the debugfs readers hold it while walking them. This permits the reset completion and a debugfs read to interleave as follows: hci_rx_work debugfs reader ----------- -------------- lock hdev->lock fetch current entry list_del(entry) kfree(entry) read entry fields The reader then dereferences a freed list entry and may follow its stale next pointer. KASAN reported: BUG: KASAN: slab-use-after-free in white_list_show+0x15f/0x180 Read of size 1 at addr ffff8881015dab16 by task poc/95 Call Trace: white_list_show+0x15f/0x180 seq_read_iter+0x3ff/0x1190 seq_read+0x267/0x3d0 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 Allocated by task 91: hci_bdaddr_list_add+0x1a6/0x3a0 hci_cc_le_add_to_accept_list+0xab/0x140 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Freed by task 90: kfree+0x131/0x3c0 hci_bdaddr_list_clear+0xd8/0x160 hci_cc_reset+0x28a/0x370 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Take hdev->lock around both list clears. This matches the existing mutation and traversal locking convention. Fixes: a4d5504d5c39 ("Bluetooth: Clear LE white list when resetting controller") Fixes: cfdb0c2d095a ("Bluetooth: Store Resolv list size") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 608f8fd8c0f7b6268da43509447802955f210aac Author: Michael Bommarito Date: Thu Jul 9 22:28:53 2026 -0400 HID: hyperv: validate initial device info bounds commit 934b7778aa7b7c8f6bb073d2a73ba3674885bae0 upstream. The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length. Fixes: b95f5bcb811e ("HID: Move the hid-hyperv driver out of staging") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 849e537160bbb77fe419ecc3944bfe125dcd441b Author: Ibrahim Hashimov Date: Tue Jul 14 19:39:46 2026 +0200 HID: uclogic: fix use-after-free of inrange_timer on remove commit 506fd50a9027340f0e9dcc587d10ccb03312dba6 upstream. uclogic_remove() cancels the pen in-range timer and then stops the device: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this "timer re-armed from another path" teardown case. Fixes: 01309e29eb95 ("HID: uclogic: Support in-range reporting emulation") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8406d4b69d48bc72fb6f8812a65a17a1f903440b Author: Haoxiang Li Date: Tue Jul 7 15:15:44 2026 +0800 HID: sensor: custom: Fix use-after-free in enable_sensor commit ad8fb82b04422f49530d2aa2753cc81d1c60102c upstream. enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state. Reported-by: Sashiko AI Review Link: https://sashiko.dev/#/patchset/20260623021950.1736413-1-haoxiang_li2024@163.com?part=1 Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1fa1591efd417e39e5e164bebea8ca7a3837c469 Author: Jann Horn Date: Fri Jul 3 20:30:02 2026 +0200 HID: core: fix number/pointer type confusion on long items commit 28abce951343fcec26e397610868efa4e1395c3f upstream. When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up. Fixes: 3dc8fc083dbf ("HID: Use hid_parser for pre-scanning the report descriptors") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5efcd7bbfaaec67d137c99aa0940fa34375db27f Author: Jiangshan Yi Date: Thu Jul 30 11:19:27 2026 +0800 HID: nintendo: stop device IO before hid_hw_stop on probe failure commit 1f74d3bff6fe04a64e02ab3661d2e0d554565aa6 upstream. nintendo_hid_probe() calls hid_device_io_start() before joycon_init() and joycon_leds_create(). If either fails, the error path jumps to err_close which calls hid_hw_close()/hid_hw_stop() without first calling hid_device_io_stop(). hid_hw_stop() does not stop device IO, so hid_input_report() may still run and access driver data that is being torn down, resulting in a use-after-free. Add an err_io_stop label that calls hid_device_io_stop() before hid_hw_close(), and point the two post-io_start error paths at it. Fixes: 2af16c1f846b ("HID: nintendo: add nintendo switch controller driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 268679f501386ad46405d42c2bcf89384cb5e256 Author: Jiangshan Yi Date: Thu Jul 30 18:15:06 2026 +0800 HID: nintendo: register input device after capabilities are set commit d723bc1fe2e72b9252234e94c11af644ec477bf7 upstream. input_register_device() exposes the device to userspace immediately. In joycon_input_create() it was called before joycon_config_rumble() configures the FF_RUMBLE capability and the memless force-feedback device, so a concurrent EVIOCSFF could dereference a NULL dev->ff. Registering early also means the initial udev event lacks button and axis information, which can make input managers ignore the device. Move input_register_device() to the end of joycon_input_create(), after all capabilities, the IMU input device and the force-feedback callbacks have been configured. Fixes: 2af16c1f846b ("HID: nintendo: add nintendo switch controller driver") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260730031927.25444-1-yijiangshan@kylinos.cn?part=1 Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://sashiko.dev/#/patchset/20260730031927.25444-1-yijiangshan@kylinos.cn?part=1 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 51cfd1adbe7a46bb08af162abb3ab3b6820e2d15 Author: Ibrahim Hashimov Date: Wed Jul 15 13:52:53 2026 +0200 HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() commit 27b376b945c0aac46fcdfcc950b14a85b874b557 upstream. joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the "(IMU)" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller. Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace. The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Use the same sizeof(struct joycon_input_report) bound here. Fixes: 2af16c1f846b ("HID: nintendo: add nintendo switch controller driver") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Silvan Jegen Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 942b89f7824f833318fa7c4d1ed9abeb679947b7 Author: Peter Zijlstra Date: Tue Aug 25 14:48:14 2026 +0200 futex: Fix might_sleep() warning in futex_pivot_pending() commit d8aa5dd97944a72d4a9e3cc79bb80fcac7d6e829 upstream. A younger me put a WARN in might_sleep() to warn about nested sleep loops. This younger me also build a wait-loop variant that can deal with it. This wait-loop variant doesn't have all the fancy wrappers, since it isn't used much. It also lacks wait-bit support. Add the wait-bit support and use it to fix the nested wait issue. Fixes: 8e7ff730dd96 ("futex: Fix race in futex_pivot_pending() during private hash resize") Reported-by: syzbot+350a93852ac854927f45@syzkaller.appspotmail.com Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260820074927.GH1246887@noisy.programming.kicks-ass.net Closes: https://syzkaller.appspot.com/bug?extid=350a93852ac854927f45 Signed-off-by: Greg Kroah-Hartman commit 86d12b34bafc9a4c271a9edefea88855a934d6e5 Author: Hyunwoo Kim Date: Tue Aug 25 14:48:10 2026 +0200 futex: Fix race on the initial mm->futex.phash.ref allocation commit bde0238083647381d4747355c5a19115a3422b96 upstream. futex_hash_allocate() allocates mm->futex.phash.ref without any locking. Commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") moved the allocation here and assumed that the process has just a single thread at this point. Commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") widened need_futex_hash_allocate_default() to cover any CLONE_VM clone, but left out vfork because the parent is suspended and cannot race. That no longer holds once vfork is nested. If a vfork child calls vfork again and is then killed with SIGKILL, the parent is released from its vfork wait and runs concurrently with the grandchild in the same mm. Neither of them went through futex_hash_allocate_default(). When both call prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) at the same time, each one sees mm->futex.phash.ref as NULL and stores its own percpu counter. Only the last store survives. The counter stored first is no longer reachable from the mm, so the references on it are not seen by __futex_ref_atomic_end(). A private hash that still has references is then considered dead and freed, and a task that still holds one of its buckets writes into freed memory in futex_q_lock(). Store the counter once with cmpxchg() and let the loser free_percpu() its own. The initial reference has to be taken before the store, otherwise another task can install a private hash while the counter is still 0. Fixes: d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") Signed-off-by: Hyunwoo Kim Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ansrpP4ImE1MaBY9@v4bel Signed-off-by: Greg Kroah-Hartman commit fdf538b2e69653ff740e84042245018e5680cd7b Author: Thomas Gleixner Date: Tue Aug 25 14:48:05 2026 +0200 futex/pi: Plug private futex exec() race commit c5f0bc9fd1cec4a00400cc727fcde03e0fde17cc upstream. The check for private futexes whether the waiter's mm, which is stored in the futex_key and copied into the pi_state, is the same as the owner's mm is not sufficient for exec(). exec() has a gap where the mm check fails to give the correct answer: exec() ... exec_release_mm() futex_exec_release() tsk::futex::exit_state = EXITING; cleanup_robust_list(); 1) tsk::futex::exit_state = OK; ... old_mm = tsk::mm; 2) tsk::mm = ->mm; Between #1 and #2 the check for the mm is wrong as that mm is about to be swapped out and eventually freed. Plug this gap by: 1) Setting tsk::futex::exit_state to FUTEX_STATE_DEAD in futex_exec_release() 2) Setting tsk::futex::exit_state to FUTEX_STATE_OK after the mm has been switched. >>From a futex point of view the task is dead after it finished the robust list cleanup up to the point where it sets the state to OK again. Fixes: 80367ad01d93 ("futex: Add basic infrastructure for local task local hash") Signed-off-by: Thomas Gleixner Reviewed-by: Kyle Zeng Acked-by: Peter Zijlstra Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4da67def9efe6a2c47827a7095716a056855054e Author: Thomas Gleixner Date: Tue Aug 25 14:48:01 2026 +0200 futex: Sanitize and document task_struct::futex::state transitions commit f9ece060cc43eae8a1f148737d193ba0d07b8f88 upstream. The futex state is used to prevent a waiter from attaching to the lock owner while the owner runs the futex cleanup in exit() or exec(). Only the state transition from FUTEX_STATE_OK to FUTEX_STATE_EXITING must be done with the task's pi_lock held, the transition away from FUTEX_STATE_EXITING has no serialization requirements on the writer side, but it's completely non obvious why. It's magically protected by exit_pi_state(), which operates under tsk::pi_lock, as that's the state which has to be correct when the waiter observes the new state. OTOH, taking the pi_lock in futex_cleanup_end() is not a performance issue because at that point the lock should be uncontended in the vast majority of cases. Aside of that the handling of FUTEX_STATE_EXITING in attach_to_pi_owner() and handle_exit_race() is confusing at best. Protect the store in futex_cleanup_end() with tsk::pi_lock, handle FUTEX_STATE_EXITING in attach_to_pi_owner() explicitly and document how this is supposed to work. Reported-by: Peter Zijlstra Signed-off-by: Thomas Gleixner Reviewed-by: Kyle Zeng Acked-by: Peter Zijlstra Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2b92e5562653b5293529f63b0300837d9dcedbd7 Author: Kyle Zeng Date: Tue Aug 25 14:47:57 2026 +0200 futex/pi: Reject cross-mm private futex owners commit 59b3732f95dda1fbd2234514d35f4fb6b5bb6d85 upstream. A private futex key borrows the waiter's mm without taking an mm_users reference. Nevertheless, attach_to_pi_owner() currently accepts an owner from a different address space and copies the private key into the owner's PI state. When that owner exits, exit_pi_state_list() uses the saved key to find the hash bucket and acquires a reference to the waiter's private hash. If the last user of the waiter's mm exits concurrently, futex_hash_free() frees the hash while the owner still uses its bucket and reference. Prevent this by validating in attach_to_pi_owner() that, for private futexes, the owner mm and waiter mm are the same. Perform the check with the owner's pi_lock held and after validating owner::futex::state to serialize against a concurrent PI-state exit cleanup. [ tglx: Amended comment ] Fixes: 80367ad01d93 ("futex: Add basic infrastructure for local task local hash") Signed-off-by: Kyle Zeng Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra Assisted-by: Codex:gpt-5.6-sol Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f303f6a4c90995873a352ba93f2bc531a4fecedf Author: Donglin Lyu Date: Mon Aug 24 10:50:35 2026 -0400 Input: atkbd - skip deactivate for HONOR ZQC-P [ Upstream commit 410c44b1096789d0c40fbee706520e981dba7bc1 ] The internal keyboard on the HONOR ZQC-P (HONOR MagicBook Pro 14 2026) does not work after boot. Using the kernel command line 'i8042.dumbkbd=1' makes the keyboard functional, but the CapsLock LED does not work. Adding the 'atkbd_deactivate_fixup' quirk fixes the keyboard and CapsLock LED natively without requiring boot parameters. DMI: HONOR ZQC-P/ZQC-P-PCB, BIOS 1.09 03/19/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Signed-off-by: Donglin Lyu Tested-by: Ruslan Shevchenko Link: https://patch.msgid.link/20260801151115.52709-1-donglin_lyu@outlook.com Cc: stable@vger.kernel.org [dtor: keep all HONOR entries together] Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 936ea65543da0f5e14852ced139d4959d883201e Author: Cryolitia PukNgae Date: Mon Aug 24 10:50:34 2026 -0400 Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard [ Upstream commit 2aaf33c6e1e82561d7dce2345298a985a2483266 ] After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR FMB-P, aka HONOR MagicBook Pro 14 2025's internal keyboard stops working. Adding the atkbd_deactivate_fixup quirk fixes it. DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025 Fixes: 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Reported-by: Mikura Kyouka Reported-by: foad.elkhattabi Signed-off-by: Cryolitia PukNgae Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20251022-honor-v1-1-ff894ed271a9@linux.dev Signed-off-by: Dmitry Torokhov Stable-dep-of: 410c44b10967 ("Input: atkbd - skip deactivate for HONOR ZQC-P") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ea8f06454012d9e7f9c6e6253df710949bf6294 Author: Xiang Mei (Microsoft) Date: Sat Jun 27 02:40:23 2026 +0000 xfrm: fix sk_dst_cache double-free in xfrm_user_policy() [ Upstream commit c283e9ada7fcb7dd4b10592623086b2e6d2f9925 ] xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged. Fixes: 2b06cdf3e688 ("xfrm: Clear sk_dst_cache when applying per-socket policy.") Fixes: be8f8284cd89 ("net: xfrm: allow clearing socket xfrm policies.") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 39fc615e355b65b8d43be30da57aa95ae6eaf688 Author: Anand Khoje Date: Thu Aug 13 08:37:05 2026 +0000 net/ionic: avoid OOB TX partner lookup for hwstamp RXQ commit d92255b405fb6f5acca408239ccd742e0a42c9cb upstream. The dedicated hardware timestamp RX queue is allocated with q->index equal to lif->ionic->nrxqs_per_lif. The normal txqcqs array only contains the regular queue pairs, so using that index to set rxq->partner can read one entry past txqcqs[] and then write through the derived pointer. Only link RX/TX partners for normal queue-pair indexes. Leave the hwstamp RX queue unpaired, and make the XDP_TX path abort cleanly if an RX queue has no TX partner. Fixes: 8eeed8373e1c ("ionic: Add XDP_TX support") Reviewed-by: Si-Wei Liu Reviewed-by: Shannon Nelson Cc: stable@vger.kernel.org Signed-off-by: Anand Khoje Reviewed-by: Simon Horman Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260813083705.454897-1-anand.a.khoje@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 4529c03c3da8f91392cd630453452f569973f4cd Author: Baul Lee Date: Sun Jul 26 15:25:03 2026 +0900 HID: pidff: fix OOB write when hid->inputs is empty commit 67bb1074e3d2d12fa059a9cc707e89398a4e4704 upstream. hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee Fixes: f06bf8d94fff ("HID: Add hid-universal-pidff driver and supported device ids") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9a1d7c5f0d82e8665715d5e47c9410c6a97e3748 Author: Baul Lee Date: Sun Jul 26 15:50:24 2026 +0900 HID: core: fix OOB read of field->usage in hid_set_field() commit a13cdb19fcb223ed41bdab3bab42b98dba87e90b upstream. hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: hid_dump_input(field->report->device, field->usage + offset, value); if (offset >= field->report_count) { hid_err(...); return -1; } Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs "offset (1) exceeds report_count (1)" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ace7fc4d38799c6dbc2b79d7e7587196bd61964c Author: Lee Jones Date: Thu Apr 16 14:16:54 2026 +0100 HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID commit d93ba918a185aca2594da63e92fdc5495b559c0f upstream. It is currently possible for a malicious or misconfigured USB device to cause an out-of-bounds (OOB) read when submitting reports using DOUBLE_REPORT_ID by specifying a large report length and providing a smaller one. Let's prevent that by comparing the specified report length with the actual size of the data read in from userspace. If the actual data length ends up being smaller than specified, we'll politely warn the user and prevent any further processing. Signed-off-by: Lee Jones Reviewed-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 15b60ade825c8ce9ec560048a4ae3747e4572be3 Author: Jose Villaseñor Montfort Date: Tue Jul 28 22:15:57 2026 -0600 HID: magicmouse: do not keep a stale msc->input if no input is claimed commit 0af3b89705688af01aa06025b84fa7a1e06ba6cc upstream. magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: if ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, connect_mask & HID_CONNECT_HIDINPUT_FORCE)) hdev->claimed |= HID_CLAIMED_INPUT; and the "device has no listeners" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the "input not registered" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well. Fixes: f1a9a149abc8 ("HID: magicmouse: fix race between input_register() and probe()") Link: https://lore.kernel.org/linux-input/20260728185542.65F091F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Jose Villaseñor Montfort Reviewed-by: Alec Hall Tested-by: Alec Hall Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 62ec3c591ee813337bf5af191f3202f11c22cf61 Author: Christopher Kodama Date: Sat Jul 25 16:34:46 2026 -0400 HID: magicmouse: re-enable multitouch after reset-resume commit 4253fe22b137c4ee68f36b707fdb1b44b191edc4 upstream. When the Apple Magic Trackpad 2 (USB) is reset across a power transition (e.g. resume from hibernation) it drops out of multitouch mode: it keeps sending report ID 0x02 on its HID_TYPE_USBMOUSE interface, but the packet shrinks from 21 to 8 bytes and the trackpad2 handler drops it (size < 12). Clicks still work but pointer motion is lost until the device is re-plugged or the driver reloaded. Re-enable multitouch from .reset_resume via the workqueue. Only .reset_resume is needed; suspend-to-idle keeps the device powered and retains multitouch. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:claude-opus-4-8 Signed-off-by: Christopher Kodama Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 02a88f8308ae7c6884b2bba9a21df4caff49bd07 Author: Andrei Fed Date: Mon Jul 6 19:55:07 2026 +0200 HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C commit a1556b48efc157fdda07b52ecc56c7bd1e1786f0 upstream. The Apple Magic Trackpad 2 (USB-C) reports a wildly wrong battery capacity over Bluetooth, for example a constant 4% for a pack that is actually at 74%. The device's battery input report (0x90) is laid out as [report-id][status][charge]. hid-input's synchronous capacity query, hidinput_query_battery_capacity(), assumes the common [report-id][capacity] layout and returns buf[1], which for this device is the status byte rather than the charge (buf[2]). magicmouse_fetch_battery(), which requests the battery report through hid_hw_request() so the reply is decoded via the report descriptor at the correct field offset, is gated to the USB models and never runs over Bluetooth. The device does not push battery reports on its own either, except a single one at connect time, which is delivered while probe holds driver_input_lock and is silently dropped. All userspace reads therefore go through the misparsing query, and the device is stuck reporting its status byte as the capacity. Enabling the fetch for Bluetooth is not sufficient on its own: user space reacts to the power_supply registration immediately, so a query is typically already in flight when the fetch reply is parsed. hidinput_get_battery_property() stores the query result and marks the battery as queried without rechecking whether a report arrived while it was waiting, clobbering the just-reported correct value with the misparsed one. Fix this by adding HID_BATTERY_QUIRK_AVOID_QUERY for the Bluetooth Magic Trackpad USB-C so the misparsing query path is never used, and by fetching the battery at the end of probe for this device. hidp has no asynchronous request() callback, so the fetch is serviced synchronously via __hid_request() while probe still holds driver_input_lock; call hid_device_io_start() first so the reply is processed instead of being discarded. Tested with a Magic Trackpad USB-C (004c:0324) over Bluetooth on 6.18.37: the reported capacity now matches the device (verified against a raw GET_REPORT of report 0x90) and updates on reconnect. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Signed-off-by: Andrei Fed Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b6baab796d11fb84c0e9444ffca91af5eab22c25 Author: Dawid Wróbel Date: Mon Aug 24 17:52:40 2026 -0400 ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses [ Upstream commit 1ba381759e45d5d0442452cfa5c42e836191a568 ] The "DEC0 MODE" to "DEC7 MODE" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow Fixes: c39667ddcfc5 ("ASoC: codecs: lpass-tx-macro: add support for lpass tx macro") Assisted-by: Claude:claude-fable-5 Cc: stable@vger.kernel.org Signed-off-by: Dawid Wróbel Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-1-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown [ kept `snd_soc_kcontrol_component()` context line instead of upstream's renamed `snd_kcontrol_chip()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9fe5eebb664ecdba88f3fde18062d94b1d1c465f Author: Shardul Bankar Date: Mon Aug 24 19:44:12 2026 -0400 mptcp: pm: fix memory leak from alloc-during-teardown race [ Upstream commit efc33b5102ff859bacd390a5f30112d8e0c084c0 ] mptcp_pm_destroy() empties msk->pm.anno_list and msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket teardown, dropping the lock between the two. A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcp_token_get_sock() and, in mptcp_pm_nl_announce_doit(), calls mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcp_pm_destroy() may run on the same msk via mptcp_disconnect(), which invokes mptcp_destroy_common() without dropping the sock refcount, before the handler completes. If the lock acquisitions interleave such that mptcp_pm_destroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and mptcp_pm_addr_entry objects (from mptcp_userspace_pm_append_new_local_addr()) under sustained concurrent ANNOUNCE + close load against the userspace PM. Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by mptcp_pm_destroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcp_pm_destroy() frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the later alloc observes the bit and refuses. Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782). Fixes: 9ab4807c84a4 ("mptcp: netlink: Add MPTCP_PM_CMD_ANNOUNCE") Cc: stable@vger.kernel.org Signed-off-by: Shardul Bankar Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-6-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6fa2064761ec05bd3d79f5168d3662fba9c0afe1 Author: Matthieu Baerts (NGI0) Date: Mon Aug 24 19:44:11 2026 -0400 mptcp: pm: uniform announced addresses helpers [ Upstream commit 7d4dacc8ccca8e40fcb5f2ece9ea3e502da1bd3f ] Similar to the previous commit, only using the 'add' or 'anno' prefixes is confusing -- generally associated to the action of adding something, or the Latin name for "year" -- and lack of uniformity. This has been causing issues in the past, e.g. del_add_timer seemed to suggest the goal is to delete a previously added timer. Instead, use the mptcp_pm_announced_ prefix. While at it, slightly improves some helpers: - mptcp_lookup_anno_list_by_saddr: no need to specify what is used to do the lookup: mptcp_pm_announced_lookup. - mptcp_pm_sport_in_anno_list: it doesn't just compare the port, but the whole address linked to the sublow: mptcp_pm_announced_has_ssk. - mptcp_pm_alloc_anno_list: it allocates one item of the list, not a whole list: mptcp_pm_announced_alloc. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-11-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: efc33b5102ff ("mptcp: pm: fix memory leak from alloc-during-teardown race") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 714c6d11aceaa62737a4e683fd803062fbaf060d Author: Matthieu Baerts (NGI0) Date: Mon Aug 24 19:44:10 2026 -0400 mptcp: pm: rename add_entry structure to add_addr [ Upstream commit 350d76dd6e79468ac85767f2d236299a135572df ] Using only the 'add' prefix is confusing: does it refer to a generic added entry or address, or specifically to ADD_ADDRs. Using add_addr removes this confusion. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-10-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: efc33b5102ff ("mptcp: pm: fix memory leak from alloc-during-teardown race") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit defc59e74c1b4dd3a7be55fd98116c6d1f38623c Author: Matthieu Baerts (NGI0) Date: Mon Aug 24 19:44:09 2026 -0400 mptcp: pm: use for_each_subflow helper [ Upstream commit f81689172429885d6c2c7c3dd4926ec626e794bb ] Similar to most places in the MPTCP code. So instead of passing the subflow list and use list_for_each_entry(subflow, list, node), pass the msk and use mptcp_for_each_subflow(msk, subflow). That's clearer and more uniform with the rest. While at it, add 'pm_' prefix for the exported one to easily identify the origin. Plus replace 'lookup' by 'has', because a bool is returned. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-9-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: efc33b5102ff ("mptcp: pm: fix memory leak from alloc-during-teardown race") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f31650243c1ab32394077f234685e89ed8dece84 Author: Yifei Gao Date: Tue Aug 4 21:36:25 2026 +0000 nvmet: pci-epf: put CQ ref on create_cq mapping failure commit 659ae9d02cb5d72c76f74fff7441eb8fb64d8f5c upstream. nvmet_pci_epf_create_cq() calls nvmet_cq_create(), which takes a reference on the controller and installs the completion queue. If the subsequent PCI address-space mapping fails or returns a too-small partial mapping, the function jumps to err_internal / err_unmap_queue without calling nvmet_cq_put(). The matching put in nvmet_pci_epf_delete_cq() is gated on NVMET_PCI_EPF_Q_LIVE, which is only set after the mapping succeeds, so teardown never releases these references. A remote PCI host that drives Create IO CQ commands with a failing PRP1/pci_addr therefore leaks the CQ and a controller reference on each attempt. Drop the CQ reference on the mapping-failure paths. The err_internal and err_unmap_queue labels are only reachable after nvmet_cq_create() has succeeded, so this pairs the create/put correctly. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 20be486d1c225402b067391e72ff5b0dd8ebff76 Author: Shin'ichiro Kawasaki Date: Thu Jul 30 15:18:39 2026 +0900 nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work() commit c9e9bb757971485b4e8414b1744507af186d72c9 upstream. nvmet_pci_epf_exec_iod_work() submits an I/O command with req->execute() and then waits for the command to complete and transfers the data back to the host. This wait is not needed for commands that do not transfer data from the device to the host. To decide whether that wait is needed, it reads iod->data_len and iod->dma_dir after calling req->execute(). However, once req->execute() is called, the command may complete asynchronously on another CPU. For commands that do not require a device-to-host data transfer, nvmet_pci_epf_queue_response() calls nvmet_pci_epf_complete_iod() directly, which can free the iod before it reads iod->data_len and iod->dma_dir, resulting in the KFENCE use-after- free: BUG: KFENCE: use-after-free read in nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf] Use-after-free read at 0x00000000fdfa6d03 (in kfence-#63): nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 kfence-#63: 0x00000000e3de0e71-0x00000000c938ad62, size=712, cache=kmalloc-1k allocated by task 10 on cpu 0 at 73.995480s (0.005122s ago): mempool_kmalloc+0x1c/0x28 mempool_alloc_noprof+0x40/0x9c nvmet_pci_epf_poll_sqs_work+0xd4/0x344 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 freed by task 131 on cpu 3 at 73.995521s (0.008385s ago): mempool_kfree+0x10/0x20 mempool_free+0x44/0x64 nvmet_pci_epf_free_iod+0x88/0x98 [nvmet_pci_epf] nvmet_pci_epf_cq_work+0xfc/0x280 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 Fix this by referring to iod->data_len and iod->dma_dir before calling req->execute(). The remaining iod accesses such as iod->status are only reached on the device-to-host read path. In this case, nvmet_pci_epf_queue_response() signals iod->done instead of freeing the iod, so the iod stays valid. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Reviewed-by: Christoph Hellwig Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 9c95f7e66c62ee6c6abedcf1c04311f430ff5833 Author: Greg Kroah-Hartman Date: Mon Jul 27 22:03:31 2026 +0200 nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations commit 737a3b535247226f6e1a7988fd9d6e63e7d6fc71 upstream. When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags. Assisted-by: gkh_clanker_2000 Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 6d27199ebe8cb223022150f74be13f154a964474 Author: Ibrahim Hashimov Date: Thu Jul 9 15:25:33 2026 +0200 nvmet-tcp: bound SGL data length before allocating command buffers commit 4a3f00262a044e8e15064b1a6860968bf0500bf4 upstream. nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: cmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 8bce9cd08aae4283badf8ddc11fbb6f57b75a81e Author: Jiang HongHui Date: Wed Jul 29 19:02:06 2026 +0800 nvmet-fc: fix invalid free in LS IOD error path commit ba98d6796d12258e837ece065d2ecb59d76ce4ff upstream. nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report. Fixes: c53432030d86 ("nvme-fabrics: Add target support for FC transport") Cc: stable@vger.kernel.org Reviewed-by: Maurizio Lombardi Assisted-by: Codex:gpt-5 Signed-off-by: Jiang HongHui Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit b26189d28442183a8b5edb754f4a6918f77ca84e Author: Bryam Vargas Date: Thu Jul 2 03:45:14 2026 -0500 nvmet-auth: zero the AUTH_RECEIVE response buffer commit 3ddcfb013322aa37eaa7a0d344b73079c38dfa21 upstream. nvmet_execute_auth_receive() allocates the response buffer with kmalloc() sized by the host-supplied AUTH_RECEIVE allocation length, but the DH-HMAC-CHAP builders write only a fixed-size message into it. The full allocation length is then copied to the wire by nvmet_copy_to_sgl(), so a remote initiator receives the bytes past the built message -- up to nearly a page of uninitialized slab -- during the pre-authentication handshake. Allocate the buffer with kzalloc() so the unwritten tail is zeroed before it is sent; conforming responses are unaffected. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 23a475ff24d29ba44b78e962ed63222225ae5b47 Author: Griffin Kroah-Hartman Date: Mon Jul 6 16:57:06 2026 +0200 dmaengine: fsl-edma: Add error handling for devm_kasprintf commit bf1af4dfdc017dfe989c0dbcf0e608dc95f1d2cb upstream. Add error handling statement to fls_edma3_irq_init() for the devm_kasprintf call. Assisted-by: gkh_clanker_2000 Cc: stable Cc: Frank Li Cc: Vinod Koul Cc: imx@lists.linux.dev Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Reviewed-by: Frank Li Link: https://patch.msgid.link/2026070605-frying-fling-b9c5@gregkh Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 364edaedf4125825781a12c84c77699780d52a16 Author: Griffin Kroah-Hartman Date: Thu Jul 9 15:16:40 2026 +0200 mailbox: mchp-ipc-sbi: Add null check for devm_kasprintf() commit b37c4d0a2fd90c0c31223acd37f763eb8953ed1a upstream. Add a check to see if devm_kasprintf() is not NULL in mchp_ipc_get_cluster_aggr_irq(), returning -ENOMEM if the function failed. Assisted-by: gkh_clanker_t1000 CC: Jassi Brar Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Jassi Brar Signed-off-by: Greg Kroah-Hartman commit 3dc98e5fe82d069dd29b124ffbdb679331dfea43 Author: Luxiao Xu Date: Wed Aug 12 20:54:38 2026 +0800 ipv6: fix use-after-free in ip6_finish_output2() commit d0d48d999b0eee6bb176ef4e39d9be868fa80f7e upstream. ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory. Fixes: e415ed3a4b8b ("ipv6: use skb_expand_head in ip6_finish_output2") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Reviewed-by: Vadim Fedorenko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/4aa3f53bc44e79572c6dd2340ec7b68ef1a3d87d.1786516730.git.rakukuip@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d9d1a676b033acabf8e5645f730486d1f8204a3f Author: Yong Wang Date: Fri Aug 14 01:35:26 2026 +0800 ipv4: reject undersized MTUs in ip_do_fragment() commit c0726f0caf8c6b3208552949e17d23634a2f3129 upstream. ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using "mtu lock 20", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Yong Wang Signed-off-by: Ren Wei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/8809ef6314b98913681b0b370a05a85c2b6cd579.1786599079.git.edragain@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f03415030579163f791c978741af7f1f2f6510b7 Author: Maarten Lankhorst Date: Tue Jun 30 15:55:20 2026 +0200 drm/xe: Fix DPT allocation paths. commit fc648757908304aedbad74f74bf58192aec383db upstream. Remove the fallback for VRAM to system memory, I tested it and that doesn't work at all, only a black screen with pipe fault errors were observed. On systems with media GT, extra latency is added when accessing stolen memory when the GT is in MC6. Since we additionally aren't counting how much memory is used for stolen and we could in theory fill up the entire stolen area with DPT's, avoid using stolen and only use the default memory region. Using stolen may also result in random system hangs under load. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+") Cc: # v6.12+ Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst Acked-by: Matthew Brost #teams (cherry picked from commit a196406a3831291598fe8e73245914f7acffdfe0) Signed-off-by: Thomas Hellström [ adapted `pin_params->alignment` to `alignment` and renamed `XE_BO_FLAG_FORCE_WC` to `XE_BO_FLAG_SCANOUT` for the pre-rename flag name ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20892d2923e489e8a108f83b6f77a22d1b2f2491 Author: Linmao Li Date: Tue Jul 21 10:35:18 2026 +0800 nfc: nci: free destination parameters when closing a connection commit 2e65bafdfd3a8bba972b3d17b6a57816557530fc upstream. When a connection is closed, nci_core_conn_close_rsp_packet() frees conn_info but not conn_info->dest_params, which is a separate devm allocation. Each connect/close cycle leaks one dest_params until the NFC device is removed. Free dest_params along with conn_info. Fixes: 9b8d1a4cf2aa ("nfc: nci: Add an additional parameter to identify a connection id") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260721023518.1697625-1-lilinmao@kylinos.cn Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 0d4b5cfab6891a5ca0f6aef209beebba4bd7c095 Author: Samuel Page Date: Fri Jun 26 10:03:01 2026 +0100 nfc: nci: fix uninit-value in the RF discover/activated NTF handlers commit 8cbe06c1e699c0a165dae5093a2550e65f914818 upstream. nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present. Fixes: 019c4fbaa790 ("NFC: Add NCI multiple targets support") Fixes: e8c0dacd9836 ("NFC: Update names and structs to NCI spec 1.0 d18") Link: https://lore.kernel.org/netdev/20260623172109.1105965-2-horms@kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page Link: https://patch.msgid.link/20260626090301.2139500-1-sam@bynar.io Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 2f08dbce3b37624ec6b424d759336a99586170ec Author: Samuel Page Date: Mon Jun 22 16:52:43 2026 +0200 nfc: nci: fix out-of-bounds write in nci_target_auto_activated() commit ac200079db50af81e6b04d058b33ec92901d8edd upstream. nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target(). Fixes: 019c4fbaa790 ("NFC: Add NCI multiple targets support") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260622145243.3167276-1-sam@bynar.io Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 9620a91f8d643b680f417a435db399a04d1e06d8 Author: Bryam Vargas Date: Fri Jun 12 12:50:25 2026 -0500 nfc: nci: add data_len bound checks to activation parameter extractors commit 0428fa2c22e2ba0cff766d3b80d461e149102045 upstream. nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 ("net: nfc: nci: Fix parameter validation for packet data"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801. Fixes: e8c0dacd9836 ("NFC: Update names and structs to NCI spec 1.0 d18") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260612-b4-disp-6d52d8b0-v3-1-e26221f8826d@proton.me Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit bfcca5f42c9aa4eadef1e5fe7bb23783d7fcc96d Author: Doruk Tan Ozturk Date: Sat Jul 11 09:13:01 2026 +0200 nfc: st21nfca: validate ATR_REQ length against the received frame commit 5cdcca5d62a66eda6b774110a44cba67bc1a8d1d upstream. st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: gb_len = atr_req->length - sizeof(struct st21nfca_atr_req); ... memcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested. Fixes: 1892bf844ea0 ("NFC: st21nfca: Adding P2P support to st21nfca in Initiator & Target mode") 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/20260711071301.58071-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 2f5d093194ec24d7c29b91bf7df014924e0f4ea1 Author: Xu Rao Date: Mon Jul 20 10:14:44 2026 +0800 nfc: pn533: purge fragmented skbs during cleanup commit 5718fc62198c38c2de5316020a90506f9e75e0bb upstream. pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q. Fixes: 963a82e07d4e ("NFC: pn533: Split large Tx frames in chunks") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/2D896607CAE4408E+20260720021444.3362044-1-raoxu@uniontech.com Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit e969e98410051b1ef8cc318bfe0c7e3f24ec766d Author: Doruk Tan Ozturk Date: Tue Jul 14 18:46:31 2026 +0200 nfc: llcp: reject PDUs shorter than the LLCP header commit 95674f506c6376d6722a23144c9acd26609771ed upstream. Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes tlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: d646960f7986 ("NFC: Initial LLCP support") Cc: stable@vger.kernel.org Suggested-by: David Laight Signed-off-by: Doruk Tan Ozturk Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260714164631.75068-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 2d239590d1845a706304833d40dd6d4fec20ad88 Author: Muhammad Bilal Date: Mon Jun 22 18:18:02 2026 +0500 nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers commit 78b20c8eeacd2e44a2d8a4cb5316d3c521d90911 upstream. nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access. Fixes: 3df40eb3a2ea ("nfc: constify several pointers to u8, char and sk_buff") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260622131802.239035-1-meatuni001@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit e87527b506c40db9af528714b7b1240918eb80fc Author: Doruk Tan Ozturk Date: Thu Jul 9 15:12:29 2026 +0200 nfc: llcp: bound the connect_sn TLV walk to the skb commit 55c68ac93e7dacc0f5f608b9c39dd4ff48cf28e8 upstream. Commit 27256cdb290e ("nfc: llcp: bound SNL TLV parsing to the skb and add length checks") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 ("nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as "skb->len - LLCP_HEADER_SIZE" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: d646960f7986 ("NFC: Initial LLCP support") 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/20260709131229.44477-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit d0902a7c454326c6384c614226ab8987f3fd425d Author: Pengpeng Hou Date: Thu Jul 23 10:37:20 2026 +0800 nfc: microread: validate target discovery payload lengths commit 25519469972ef57c3edb1805dabd6c5612b90211 upstream. microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them. Fixes: cfad1ba87150 ("NFC: Initial support for Inside Secure microread") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260723103508.1-microread-v2-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit db7e464b350969c6ea8340de00d9796e5fd5123b Author: Bryam Vargas Date: Tue Jun 16 23:33:35 2026 -0500 nfc: fdp: bound the device-reported read length and fix an skb leak commit 7ad21dcfeb5181af0c3ee2608808c0c0a5283aa1 upstream. fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next. Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver") Cc: stable@vger.kernel.org Suggested-by: Simon Horman Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260616-b4-disp-b1f8ab4c-v2-1-2d1fe5955325@proton.me Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit a56773e649ea99b344d6bbaf90f34c8e3fadef5d Author: Doruk Tan Ozturk Date: Wed Jun 3 16:13:55 2026 +0200 nfc: digital: clamp SENSF_RES length to the destination buffer commit 344a56d7c8e0f3cbaff0bcb1bcd95a1a1db24b16 upstream. digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 8c0695e4998d ("NFC Digital: Add NFC-F technology support") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260603141355.68156-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit cb8246e5846dbbe34930903a90c7a90dd8e5910b Author: Pavitra Jha Date: Mon Aug 24 07:15:07 2026 -0400 libceph: fix OOB read in decode_watchers() via missing bounds check [ Upstream commit 00ead17c7de137a692edee59f2772e6af687e8eb ] ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ] Cc: stable@vger.kernel.org Fixes: a4ed38d7a180 ("libceph: support for CEPH_OSD_OP_LIST_WATCHERS") Signed-off-by: Pavitra Jha Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov [ kept the tree's `kcalloc()` context line instead of upstream's `kzalloc_objs()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 184c1a80421a5b5ddcd262e47980ce2e67fee211 Author: Hongling Zeng Date: Tue Jul 28 15:43:40 2026 +0800 xfs: validate attr entry pointer before field access commit b7eea80be25f3334f131d52982b3131aba77b97d upstream. xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access. Fixes: c84760659dcf2 ("xfs: check attribute leaf block structure") Cc: # v5.5 Signed-off-by: Hongling Zeng Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e0e7f464d6ce89fdd867dd96cbaf4ae0ae0b3020 Author: Jiazi Liu Date: Mon Jul 27 18:41:03 2026 +0800 ext4: fix incorrect function call when initializing s_resgid commit c87abbab6147dcc5aa1fd8f2a61734d58d8b99ec upstream. In __ext4_fill_super(), s_resgid is initialized by calling ext4_get_resuid() instead of ext4_get_resgid(), resulting in the reserved GID being set to the same value as the reserved UID rather than the value stored in the superblock. Fixes: 12c84dd4d308 ("ext4: add support for 32-bit default reserved uid and gid values") Cc: stable@vger.kernel.org Signed-off-by: Jiazi Liu Reviewed-by: Ritesh Harjani (IBM) Link: https://patch.msgid.link/20260727104103.28916-1-liujiazi@amazon.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 458776af0061afec1014cb3cd0061e282e482e83 Author: Eric Biggers Date: Thu Jul 30 10:52:12 2026 -0700 ext4: don't enable DAX on new encrypted files commit da32af420d6d466e247c43ac0b829edeac7ae0ad upstream. Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with "-o dax=always". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when "-o dax=always" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too. Reported-by: Disha Goel Reported-by: Ojaswin Mujoo Closes: https://lore.kernel.org/r/20260723085648.1500357-1-ojaswin@linux.ibm.com Fixes: 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Tested-by: Disha Goel Reviewed-by: Ojaswin Mujoo Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260730175212.36923-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f3d2fa3a99336e20cb70e7c61946264d7e24f3bf Author: Guanghui Yang <3497809730@qq.com> Date: Wed Jul 8 08:12:04 2026 +0000 ext4: propagate errors from fast commit range replay commit d8b8dd3530bf41e14b118702cdaf9de64bb96885 upstream. ext4_fc_replay() stops replaying fast commit tags only when a tag handler returns a negative error. However, ext4_fc_replay_add_range() and ext4_fc_replay_del_range() currently return 0 from their common exit paths even after internal failures. This hides errors from ext4_fc_record_modified_inode(), ext4_map_blocks(), ext4_find_extent(), ext4_ext_insert_extent(), ext4_ext_replay_update_ex(), and ext4_ext_remove_space(). As a result, a failed ADD_RANGE or DEL_RANGE replay can be treated as successful and the replay code may continue with subsequent fast commit tags. This is particularly problematic for DEL_RANGE because it may already have marked blocks as free before ext4_ext_remove_space() fails. If the error is swallowed, replay may continue from a partially applied range operation. Return the saved error from the common exit paths and make the ERR_PTR() cases in ADD_RANGE store PTR_ERR() before jumping to out. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@vger.kernel.org Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: Jan Kara Link: https://patch.msgid.link/tencent_E3622146846A84C75C31C7D32AC4D5AD0605@qq.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 5f46f084f74b5f425f6b0b140c6a9ebe6939a944 Author: Jia Zhu Date: Tue Jun 9 11:52:02 2026 +0800 ext4: avoid tail write_begin walk for uptodate folios commit d09811183db2891776dbf0c0f1094540e29938f6 upstream. Ext4 buffered writes into large folios also pay a full buffer_head walk in ext4_block_write_begin(). For a small overwrite of an existing cached folio, the folio is already uptodate and the write only needs to prepare the buffers through the written range. Walking the suffix still makes the write_begin cost proportional to the folio size. Before ext4 enabled large folios for regular files, the same loop was bounded by a single page of buffers. That commit made the existing full-folio walk visible as a regression for cached small overwrites. The suffix walk is needed for non-uptodate folios, where ext4 may have to submit reads for partial blocks, preserve new-buffer cleanup, and run error zeroing. Keep those folios on the old full walk. For already-uptodate folios, keep the walk starting at the first buffer rather than seeking directly to from. This preserves the existing prefix buffer state handling. Stop once block_start reaches the end of the write range, because the skipped suffix would only repeat the outside-range uptodate handling for buffers beyond @to. On current master, the libMicro ext4 large-folio overwrite test shows the following full-series result. Results are median usecs/call over 10 runs, lower is better: case nofix this series improvement write_u1k 1.418 0.3405 76.0% write_u10k 1.887 0.4175 77.9% pwrite_u1k 1.6775 0.3390 79.8% pwrite_u10k 1.9035 0.4130 78.3% Fixes: 7ac67301e82f0 ("ext4: enable large folio for regular file") Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jan Kara Signed-off-by: Jia Zhu Link: https://patch.msgid.link/20260609035202.90669-3-zhujia.zj@bytedance.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit fb5980fbe44fcb5325c37bf19bec0a5a6ffd08eb Author: Guanghui Yang <3497809730@qq.com> Date: Wed Jul 8 12:57:19 2026 +0000 ext4: clear error before retrying inode xattr space fallback commit 409a7f12a0933ff2c617fa814c76cef0bd1d457a upstream. When ext4_xattr_make_inode_space() returns -ENOSPC, ext4_expand_extra_isize_ea() can retry the expansion with s_min_extra_isize. If that retry succeeds by finding enough ibody free space, control jumps directly to the shift label. The previous -ENOSPC is still stored in error in that path, so the function can update i_extra_isize but still return -ENOSPC to the caller. Clear error before retrying so a successful fallback expansion returns success. Reproduced with an ext4 image using 1 KiB blocks, project quota support, 256-byte inodes, and min_extra_isize/want_extra_isize set to 32. FS_IOC_FSSETXATTR failures dropped from 802 to 86 after the fix. Fixes: 69f3a3039b0d ("ext4: introduce ITAIL helper") Cc: stable@vger.kernel.org Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: Jan Kara Link: https://patch.msgid.link/tencent_192F8A699EFD21126E02101131C9546F3C08@qq.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e447f7edb99bd00cec63d6f3049e2e5074946f71 Author: Ryusuke Konishi Date: Fri Jul 3 01:07:19 2026 +0900 nilfs2: reject invalid block index in GC ioctl commit a1735eae55448bc79c2da6593455791e886f6ed8 upstream. Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions. Reported-by: syzbot+c37bed40868932d790e9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c37bed40868932d790e9 Fixes: 7942b919f732 ("nilfs2: ioctl operations") Cc: wuyankun Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit 4902a5cba21aeaf91e6b29e20e0967a5f6abdcd9 Author: Matthias Goergens Date: Sun Aug 2 14:59:41 2026 +0800 ext4: stop retrying saturated xattr cache entries commit 54b6bd40898de7906acb2bccc9a96d1b8e6b4323 upstream. ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang. Reported-and-tested-by: syzbot+e68dbebd9617a9250e8d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e68dbebd9617a9250e8d Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Jan Kara Reported-by: syzbot+e68dbebd9617a9250e8d@syzkaller.appspotmail.com Tested-by: syzbot+e68dbebd9617a9250e8d@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260802065941.1726052-1-matthias.goergens@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e11f5b48c82703242a3be7a7ae4b4940b4cb4610 Author: Tetsuo Handa Date: Thu Jul 16 08:01:29 2026 +0900 kcov: fix data corruption and race conditions on PREEMPT_RT commit 2eed77fdcb0cc48e8eccb2bcd4b7f2c6d650e84c upstream. syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems. Link: https://lore.kernel.org/43552d09-2ce2-4b19-b0d3-a2d1ab952145@I-love.SAKURA.ne.jp Reported-by: syzbot+3f51ad7ac3ae57a6fdcc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc Reported-by: syzbot+47cf95ca1f9dcca872c8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=47cf95ca1f9dcca872c8 Reported-by: syzbot+8a173e13208949931dc7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8a173e13208949931dc7 Reported-by: syzbot+90984d3713722683112e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=90984d3713722683112e Analyzed-by: AI Mode in Google Search (no mail address) Fixes: 5ff3b30ab57d ("kcov: collect coverage from interrupts") Signed-off-by: Tetsuo Handa Reviewed-by: Alexander Potapenko Cc: Alan Stern Cc: Andrey Konovalov Cc: Christoph Hellwig Cc: Clark Williams Cc: Dmitry Vyukov Cc: Greg Kroah-Hartman Cc: Marco Elver Cc: Mark Brown Cc: Roman Gushchin Cc: Sebastian Andrzej Siewior Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 164ca33cf536649c62fa958869534c8cf4eb088a Author: Rik van Riel Date: Sat Aug 8 11:42:39 2026 -0400 null_blk: fix UBSAN shift-out-of-bounds when zone_size is 0 or overflows commit 95491fb05105b61050cb623a5e0227eb26aa3525 upstream. null_zone_no() does sect >> ilog2(dev->zone_size_sects). When zone_size_sects is 0, ilog2(0) returns -1, producing shift exponent -1 which UBSAN reports as shift-out-of-bounds. UBSAN: shift-out-of-bounds in drivers/block/null_blk/zoned.c:21:14 shift exponent -1 is negative Call Trace: null_zone_no drivers/block/null_blk/zoned.c:21 [inline] null_process_zoned_cmd+0xf76/0xf80 drivers/block/null_blk/zoned.c:728 null_handle_cmd drivers/block/null_blk/main.c:1455 [inline] null_queue_rq+0x8bc/0xe70 drivers/block/null_blk/main.c:1703 __blk_mq_issue_directly block/blk-mq.c:2694 [inline] blk_mq_try_issue_directly+0x3f4/0x880 block/blk-mq.c:2754 blk_mq_submit_bio+0x20c0/0x2a40 block/blk-mq.c:3208 submit_bio_noacct_nocheck+0x2f4/0xa40 block/blk-core.c:790 block_read_full_folio+0x7a6/0x810 fs/buffer.c:2463 filemap_read_folio+0x12c/0x3a0 mm/filemap.c:2510 read_part_sector+0xb6/0x2b0 block/partitions/core.c:724 adfspart_check_ICS+0xb1/0x960 block/partitions/acorn.c:357 check_partition block/partitions/core.c:143 [inline] blk_add_partitions block/partitions/core.c:591 [inline] bdev_disk_changed+0x851/0x17a0 block/partitions/core.c:695 blkdev_get_whole+0x372/0x510 block/bdev.c:751 add_disk_final block/genhd.c:412 [inline] add_disk_fwnode+0x24b/0x3a0 block/genhd.c:606 null_add_dev+0x130b/0x1d70 drivers/block/null_blk/main.c:2052 nullb_device_power_store+0x240/0x380 drivers/block/null_blk/main.c:501 configfs_write_iter+0x337/0x430 fs/configfs/file.c:229 Syzkaller triggers this by creating a zoned null_blk device via configfs. The Call Trace shows configfs_write_iter in configfs/file.c handling a write to power file, which calls nullb_device_power_store in main.c, which calls null_add_dev in main.c, which calls add_disk in genhd.c, which triggers partition scan via bdev_disk_changed in partitions/core.c. A zoned null_blk device with zone_size 0 should not be legal. Existing code tries to reject it via is_power_of_2() check in zoned.c and !zone_size check in main.c, but syzkaller can still reach null_zone_no() with zone_size_sects 0 via two paths: 1. Direct 0 via configfs: zone_size attribute store in main.c has NULLB_DEVICE_ATTR(zone_size, ulong, NULL) with no validation callback, so echo 0 > zone_size succeeds before power store. If zoned is false at power store time, the !zone_size check in main.c is skipped, and later zoned set true leaves zone_size 0. 2. Large value overflow: mb_to_sects() in zoned.c does (sector_t)mb * SZ_1M >> SECTOR_SHIFT which is mb * 2048. If mb is 1UL << 53 (9PB), mb * 2048 overflows 64-bit to 0. The value is power-of-two so is_power_of_2() passes, but mb_to_sects() returns 0. Check for zero zone_size explicitly in null_init_zoned_dev() in zoned.c, returning -EINVAL with "must be non-zero power-of-two". Check for zero zone_size_sects after mb_to_sects() conversion, returning -EINVAL for overflow case. Keep defensive check in null_zone_no() returning 0 for zero sectors to avoid shift out-of-bounds even if zero slips through. This change should be safe because zone_size is set once in null_init_zoned_dev() under device lock and never changes after, and 0 is never valid for a zoned device. Returning -EINVAL at init time fails device creation early with clear error, while defensive return 0 in null_zone_no() makes zoned command fail via offline zone check. No new locking is introduced. Reported-by: syzbot+abd6a8dca0f2b7726060@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=abd6a8dca0f2b7726060 Link: https://lore.kernel.org/all/6a75205c.01d0871a.3a0d52.0033.GAE@google.com/ Fixes: 8a3cf049af68 ("null_blk: add zoned block device emulation") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260808114239.69167f68@fangorn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6176313622e34fa3e2b66b9d0682d1e1c6b365c5 Author: Ian Bridges Date: Thu Jul 23 23:57:03 2026 -0500 ocfs2: fix missing metadata reservation for large xattrs commit 0cdc7dde00ec63ac714271fa8b2918d630b8da1a upstream. [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel. Link: https://lore.kernel.org/amLwn3i9tET8yhG7@dev Fixes: a78f9f466894 ("ocfs2: make xattr extension work with new local alloc reservation.") Signed-off-by: Ian Bridges Reported-by: syzbot+e538032956b1157914a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e538032956b1157914a3 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 15ccf53709859bc5c345bd040d83cb6a31a73495 Author: Jens Axboe Date: Sat Aug 15 17:53:44 2026 -0600 io_uring/uring_cmd: don't skip completion for a synchronous multishot cmd commit 360941242f09437a1e07cbed9b5a96663ffeabb6 upstream. If IORING_URING_CMD_MULTISHOT is set, io_uring_cmd() treats any non-negative return from ->uring_cmd() as the driver having taken ownership of the request and returns IOU_ISSUE_SKIP_COMPLETE. But nothing guarantees that the driver did so, and any handler that just completes the command inline and returns 0 or a positive result then leaves the request orphaned, leaking the io_kiocb, the async data, and the file reference. The special case isn't needed. ublk returns -EIOCBQUEUED for the multishot fetch command, which is passed through as-is, and the poll driven socket timestamp command returns -EAGAIN. Kill it, a multishot handler that wants to hang on to the request must return -EIOCBQUEUED or -EAGAIN like any other command. Fixes: 620a50c92700 ("io_uring: uring_cmd: add multishot support") Cc: stable@vger.kernel.org Reported-by: syzbot+a4ccdd7ebf452e4d4701@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a7a0194.b50370da.49fe0.0056.GAE@google.com/ Link: https://lore.kernel.org/all/20260811115125.1831170-1-vasilisalmpanis@gmail.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 45c945107e007b1fb73e21cd220277652a45521a Author: Ali Ahmet Memis Date: Sun Aug 2 16:30:30 2026 +0000 io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec() commit 3f3a6a16bbe8bde76532d9415438f8cdef439e5d upstream. io_vec_fill_bvec() computes the folio size with a plain int 1: unsigned long folio_size = 1 << imu->folio_shift; imu->folio_shift is unsigned int and comes from folio_shift() of the folio backing the registered buffer, so it can be 32 or more on a 64 bit kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the count is taken modulo 32, so a shift of 34 yields 4 rather than 16G. Every other folio_shift shift in this file already uses 1UL. The result is that the segment estimate and the fill loop disagree. io_estimate_bvec_size() sizes the bvec array with the real shift: max_segs += (iov[i].iov_len >> shift) + 2; so a 1M iovec on a 16G folio is charged 2 segments, while io_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4 bytes and writes res_bvec[bvec_idx] a quarter of a million times, past the end of the array it was given. src_bvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validate_fixed_range() only checks that the range is inside the registered buffer and does not bound the segment count. Reaching it needs a folio with a shift of at least 32, which means a gigantic hugetlb page: 16G on arm64 with 64K pages, where CONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) registers that size, and likewise on powerpc. x86_64 tops out at 1G, so a shift of 30, which still fits in int and is unaffected. Use 1UL, as the rest of the file does. Fixes: 9ef4cbbcb4ac ("io_uring: add infra for importing vectored reg buffers") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260802163030.51005-1-ali@iusegentoo.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4074ae2f1da9e34c2f011a4c903b58d9de8c41d6 Author: Vishnu Razdan Date: Tue Aug 11 00:01:27 2026 -0700 io_uring/io-wq: fix worker accounting when canceling creation callbacks commit 297b5ccea4acacaa47c150f043bce695202afbf1 upstream. create_worker_cb() reserves an io-wq worker slot only after its task-work callback runs. If the callback is canceled before then, io_worker_cancel_cb() still decrements acct->nr_workers. When an existing worker retires with its creation callback pending, that worker has already decremented the same account's worker count. The resulting undercount permits worker creation beyond the account's configured limit. On an AST2600 OpenBMC system, an unchanged sensor daemon reached 4,291 threads with the original kernel. With an equivalent downstream fix, 25 passive samples under its normal workload showed 6-9 threads. Decrement nr_workers only when the canceled callback is not create_worker_cb(). Continuation callbacks still release their reserved slot, and both callback types retain the existing running-count, reference-count, and create-state cleanup. Fixes: 1d5f5ea7cb7d ("io-wq: remove worker to owner tw dependency") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Vishnu Razdan Reviewed-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260811-vrazdan-io-wq-b4-submit-v1-1-719ced16c921@openai.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b6a768aa975b9ca81b92f028bdd975d1f8237894 Author: Woraphat Khiaodaeng Date: Sun Aug 2 14:35:18 2026 +0700 io_uring/cmd: fix iovec leak when the async cmd is not recycled commit bb34ae5da3365699d53a756f4c96b6ea9f8ba0c1 upstream. An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the vec has to grow and kept across recycling through ctx->cmd_cache. On two paths nothing frees it and io_clean_op()'s kfree(req->async_data) drops the io_async_cmd without it. io_req_uring_cleanup() clears the async data flags only when io_alloc_cache_put() succeeds, and the cache holds IO_ALLOC_CACHE_MAX == 128 entries, so once it is full the put fails and the vec is left behind. An NVMe passthrough workload gets there without doing anything unusual: nvme_uring_cmd_io() returns -EIOCBQUEUED, so the io_async_cmd stays attached for the lifetime of the command and the live object count tracks the queue depth. Above 128 the puts start failing. ->cleanup is the last chance to free an inherited vec, since io_req_uring_cleanup() returns early for an io-wq issued command and is not called at all for one completed without ever being issued. But io_clean_op() calls ->cleanup only if REQ_F_NEED_CLEANUP is set, and for uring_cmd that happens only where the vec has to grow, so a command reusing a large enough cached vec never sets it. io_rw_alloc_async() and io_msg_alloc_async() flag an inherited vec for exactly this reason; io_uring_cmd_prep() does not. Flag an inherited vec in io_uring_cmd_prep(), and free the vec when the cache put fails, as io_req_rw_cleanup() does. The leak is invisible under KASAN, where io_alloc_cache_vec_kasan() frees the vec unconditionally. Fixes: 3a4689ac109f ("io_uring/cmd: add iovec cache for commands") Cc: stable@vger.kernel.org Signed-off-by: Woraphat Khiaodaeng Link: https://patch.msgid.link/20260802073518.419-1-worapat.kd2@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f20c2c32ec1c5c3526f29a03b487c55a5890996c Author: Takashi Iwai Date: Thu Aug 6 12:04:31 2026 +0200 ALSA: dummy: Check card index validity at probe commit 02442d5fe8ee365a084b055d4fa81a0c1abfc3fd upstream. snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Reported-by: syzbot+2fb5d1f7cc4c1f132bcc@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a73bd4d.01d0871a.3a0d52.0005.GAE@google.com Cc: Link: https://patch.msgid.link/20260806100433.1287393-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3da64f2ed902b991489c4ae63ac50104a7006f2e Author: Jens Axboe Date: Thu Jul 30 06:50:13 2026 -0600 io_uring/futex: don't mark futex wake requests as inflight commit 73e7019097473fc9f83a334ef2c6ab3343709fef upstream. Commit 079afb081c42 ("io_uring/futex: mark wait requests as inflight") added inflight tracking to ensure that do_exit() -> io_uring_files_cancel() finds and cancels pending futex waits before the mm goes away, as a private futex wait depends on the mm private futex hash staying alive for the duration of the request. However, as io_futex_prep() is shared between FUTEX_WAIT and FUTEX_WAKE, wake requests got marked as inflight as well. A futex wake executes fully inline at issue time and never depends on the mm staying alive after completion, hence there's no need to track it. Kill it. Cc: stable@vger.kernel.org Fixes: 079afb081c42 ("io_uring/futex: mark wait requests as inflight") Reported-by: Chengfeng Lin Link: https://lore.kernel.org/io-uring/CANGjgdn=R_qyUdE=j9za+vkmqcxacbP-84OHXF4nZ4ho9qRyVg@mail.gmail.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 61dc1a37e04d4003a19095f54883358330034a39 Author: Guixin Liu Date: Tue Aug 4 10:18:57 2026 +0800 nvmet: fix NULL pointer dereference in nvmet_execute_identify_nslist() commit 79aba4c9403419d822972d2851f2a96a2c0531cf upstream. When a host issues an Identify command with CNS 07h (Active Namespace ID List for a specific I/O Command Set), nvmet_execute_identify_nslist() is called with match_css set. The command-set filter dereferences req->ns, but this handler never calls nvmet_req_find_ns(), so req->ns is always NULL (nvmet_req_init() resets it to NULL). As soon as an enabled namespace with an NSID greater than the requested value exists, req->ns->csi dereferences a NULL pointer and oopses. Besides the crash, the comparison is logically wrong: to filter the list by command set it must test the command set of the namespace being iterated, not a single fixed value. Use the loop variable ns->csi. Fixes: 61c9967cd634 ("nvmet: implement active command set ns list") Signed-off-by: Guixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit e971d956353d382ee2185d71c47b538501a43f76 Author: Griffin Kroah-Hartman Date: Thu Jul 9 14:24:01 2026 +0200 rndis_host: add overflow check in rndis_rx_fixup() commit 965a251f23ff69cfb4486974d4532e9bb551c7fc upstream. Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer. Cc: Andrew Lunn Cc: Shaoxu Liu Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Reviewed-by: Simon Horman Link: https://patch.msgid.link/2026070900-denim-brook-52d4@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4305e4b52acc0ca67dcfdf8f73dd943dab508ae8 Author: Geoffrey D. Bennett Date: Mon Aug 10 03:36:11 2026 +0930 ALSA: scarlett2: Use a private URB for the notification endpoint commit cd17d6ff7b7d2b1dd9bcc80ae7b4a83773f918c6 upstream. scarlett2_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the UAC2 status interrupt endpoint and mixer.c manages. On a device with that endpoint, the "already in use" check fires on the status URB and returns 0 for success without doing anything. No notification URB is submitted, and cmd_done is left zeroed because it is initialised past that check and nowhere else. scarlett2_usb_init() then issues SCARLETT2_USB_INIT_1 and wait_for_completion_timeout() would crash adding to the zeroed wait.head. Use a separate URB in scarlett2_data, as done for FCP, and initialise cmd_done in scarlett2_init_private(). mixer.c was also freeing the URB in snd_usb_mixer_free() and resubmitting it in snd_usb_mixer_activate(), so scarlett2 must now do both: add scarlett2_cleanup_urb(), called from private_free and private_suspend, and a private_resume callback to re-establish the URB after resume. scarlett2_init_notify() is reached from there, and the URB kill path in scarlett2_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it. Also free the URB if the transfer buffer allocation fails, and both if usb_submit_urb() fails. Move scarlett2_init_notify() up next to scarlett2_cleanup_urb() so scarlett2_init_private() can reference it without a forward declaration. Fixes: 1b65088958ca ("ALSA: scarlett2: Implement handling of the ACK notification") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/ffb8ba37d5d605dfdfd8576949d67098651f9349.1786290885.git.g@b4.vu Signed-off-by: Greg Kroah-Hartman commit 65aceb45ca91ddb7f7ed178821f481b34da35543 Author: Geoffrey D. Bennett Date: Mon Aug 10 03:36:01 2026 +0930 ALSA: FCP: Use a private URB for the notification endpoint commit 918b8d231c571c50a00efe92ffc8404a537a0490 upstream. fcp_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the optional UAC2 status interrupt endpoint and mixer.c kills, resubmits and frees. On a device with that endpoint, fcp_init_notify()'s "already set up" early return fires on the status URB and returns success without doing anything. No FCP notification URB is submitted, and cmd_done is left zeroed because it is initialised past that early return and nowhere else. fcp_init() then issues init1_opcode and wait_for_completion_timeout() would crash adding to the zeroed wait.head. fcp_cleanup_urb() would also kill and free mixer.c's status URB. Use a separate URB in fcp_data, and initialise cmd_done in fcp_init_private() where fcp_data is allocated. fcp_init_notify() is reached again after suspend via fcp_reinit(), and the URB kill path in fcp_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it. Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/2cad281e6434024ca48a9ecc94fa19d6777e9be7.1786290885.git.g@b4.vu Signed-off-by: Greg Kroah-Hartman commit 7596354148c5aa12dfaa17992d1aef1aa2ea831a Author: Peiyang He Date: Thu Aug 6 12:50:59 2026 +0800 iommu/iommufd: Fix NULL pointer deref in iommufd_ioas_change_process when racing with iopt_map_file_pages commit d616de490ec0242dcf78f02f1adf7baa035c4d0d upstream. iommufd_ioas_change_process() iterates every IOAS area while only holding every IOAS iova_rwsem, so it assumes every area has a non-NULL pages pointer. That assumption can be false when it runs concurrently with iopt_map_file_pages(). iopt_map_pages() executes in two phases. It first creates the area and inserts it into the interval tree under iova_rwsem, with area->pages still NULL. It then drops iova_rwsem and later fills area->pages under domains_rwsem. This leaves a window between area creation and area->pages fill where a concurrent iommufd_ioas_change_process() can observe the area and dereference a NULL area->pages pointer, leading to a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 00000000000000c0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4b655067 P4D 4b655067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 11841 Comm: syz.1.628 Not tainted 7.1.0 #3 PREEMPT(full) 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 RIP: 0010:iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c:538 Code: 48 89 c3 48 85 c0 0f 84 cc 00 00 00 e8 10 f5 cb fd 48 8d 7b 68 e8 a7 b5 eb fd 48 8b 6b 68 48 8d bd c0 00 00 00 e8 17 b2 eb fd <8b> ad c0 00 00 00 bf 01 00 00 00 89 ee e8 85 ef cb fd 83 fd 01 74 RSP: 0018:ffffc90015c17d28 EFLAGS: 00010246 RAX: ffff8880186d5328 RBX: ffff88801d25e240 RCX: 0000000080000000 RDX: 00000000000002d7 RSI: ffffffff83ba9e10 RDI: 00000000000000c0 RBP: 0000000000000000 R08: ffffffff8e781eb8 R09: 0000000000000000 R10: 00000000000000c0 R11: ffffffff83ba9e29 R12: ffff88802e216008 R13: ffff88802e216000 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f4aea3f66c0(0000) GS:ffff8880b1fa1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000004b75c000 CR4: 0000000000350ef0 Call Trace: iommufd_fops_ioctl+0x287/0x400 drivers/iommu/iommufd/main.c:533 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x120/0x170 fs/ioctl.c:583 x64_sys_call+0x1092/0x1fb0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x10a/0x680 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4aec1a82bd 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:00007f4aea3f6018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f4aec436090 RCX: 00007f4aec1a82bd RDX: 0000200000000180 RSI: 0000000000003b92 RDI: 0000000000000003 RBP: 00007f4aec250295 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f4aec436128 R14: 00007f4aec436090 R15: 00007ffd04ef23e0 Modules linked in: CR2: 00000000000000c0 ---[ end trace 0000000000000000 ]--- RIP: 0010:iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c:538 Code: 48 89 c3 48 85 c0 0f 84 cc 00 00 00 e8 10 f5 cb fd 48 8d 7b 68 e8 a7 b5 eb fd 48 8b 6b 68 48 8d bd c0 00 00 00 e8 17 b2 eb fd <8b> ad c0 00 00 00 bf 01 00 00 00 89 ee e8 85 ef cb fd 83 fd 01 74 RSP: 0018:ffffc90015c17d28 EFLAGS: 00010246 RAX: ffff8880186d5328 RBX: ffff88801d25e240 RCX: 0000000080000000 RDX: 00000000000002d7 RSI: ffffffff83ba9e10 RDI: 00000000000000c0 RBP: 0000000000000000 R08: ffffffff8e781eb8 R09: 0000000000000000 R10: 00000000000000c0 R11: ffffffff83ba9e29 R12: ffff88802e216008 R13: ffff88802e216000 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f4aea3f66c0(0000) GS:ffff8880b1fa1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000004b75c000 CR4: 0000000000350ef0 ---------------- Code disassembly (best guess): 0: 48 89 c3 mov %rax,%rbx 3: 48 85 c0 test %rax,%rax 6: 0f 84 cc 00 00 00 je 0xd8 c: e8 10 f5 cb fd call 0xfdcbf521 11: 48 8d 7b 68 lea 0x68(%rbx),%rdi 15: e8 a7 b5 eb fd call 0xfdebb5c1 1a: 48 8b 6b 68 mov 0x68(%rbx),%rbp 1e: 48 8d bd c0 00 00 00 lea 0xc0(%rbp),%rdi 25: e8 17 b2 eb fd call 0xfdebb241 * 2a: 8b ad c0 00 00 00 mov 0xc0(%rbp),%ebp <-- trapping instruction 30: bf 01 00 00 00 mov $0x1,%edi 35: 89 ee mov %ebp,%esi 37: e8 85 ef cb fd call 0xfdcbefc1 3c: 83 fd 01 cmp $0x1,%ebp 3f: 74 .byte 0x74 Fix by mirroring the handling logic in iopt_unmap_iova_range(), i.e. return -EBUSY if area->pages is NULL. Fixes: 829ed626499c ("iommufd: Add IOMMU_IOAS_CHANGE_PROCESS") Link: https://patch.msgid.link/r/7344B7A7B9957A65+20260806045059.1884737-1-peiyang_he@smail.nju.edu.cn Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit d2ab08437e913d9e4dda4dfd0d327446ec8717fc Author: Shameer Kolothum Date: Mon Jun 29 10:41:06 2026 +0100 iommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardown commit 9ff145a25c5c8a26b06ef7cf558fb536b18bba6d upstream. arm_smmu_impl_remove() is registered as a devres action in arm_smmu_impl_probe(), before arm_smmu_init_queues() allocates smmu->cmdq.q.base. On a devres unwind, whether a failed probe or an unbind, the queue is freed first and arm_smmu_impl_remove() then runs tegra241_cmdqv_remove_vintf(), whose VINTF deinit issues a CMD_SYNC on the freed memory. Observed during testing with a QEMU hack that makes the VCMDQ fail to enable, so the impl reset fails and probe aborts into the devres unwind: platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: failed to enable, STATUS=0x00000000 platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: GERRORN=0x0, GERROR=0x4, CONS=0x0 platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: uncleared error detected, resetting arm-smmu-v3 arm-smmu-v3.0.auto: failed to reset impl arm-smmu-v3 arm-smmu-v3.0.auto: probe with driver arm-smmu-v3 failed with error -110 Unable to handle kernel paging request at virtual address ffff8000891e0098 ... Internal error: Oops: 0000000096000047 [#1] SMP ... Call trace: arm_smmu_cmdq_issue_cmdlist+0x320/0x6fc (P) tegra241_vcmdq_hw_deinit+0x98/0x168 tegra241_vintf_hw_deinit+0x5c/0x1b0 tegra241_cmdqv_remove_vintf+0x34/0xec tegra241_cmdqv_remove+0x40/0x9c arm_smmu_impl_remove+0x20/0x30 devm_action_release+0x14/0x20 devres_release_all+0xa8/0x110 device_unbind_cleanup+0x18/0x84 really_probe+0x1f0/0x29c Drop the VINTF deinit from tegra241_cmdqv_remove_vintf() so the unwind no longer touches the freed queue. Quiesce the VINTFs earlier instead. Add a device_disable() impl op and run it from arm_smmu_disable_action() while the CMDQ is still up. That handles a live unbind. A failed reset is already handled because tegra241_vintf_hw_init() deinits the VINTF on its own error path. tegra241_cmdqv_remove_vintf() is also used by the iommufd viommu destroy path, so quiesce there too. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Cc: stable@vger.kernel.org Reviewed-by: Nicolin Chen Signed-off-by: Shameer Kolothum Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d4b1a13b1eff2e80925c7368ffdeaaa50cba93df Author: Ali Ahmet Memis Date: Fri Aug 7 02:03:44 2026 +0000 Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept commit 43a556b2fd43f2df6dded59c2e26560a27874c24 upstream. rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; } and rfcomm_dlc_accept() dereferences the session on its first line: struct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as "called under rfcomm_lock()". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel 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, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side. Fixes: bb23c0ab8246 ("Bluetooth: Add support for deferring RFCOMM connection setup") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 0c55707bd5d0d7670704cfd0dda933809b052f67 Author: Steffen Persvold Date: Thu Jul 9 14:24:46 2026 +0200 PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems commit 008cb88edb41f3c7c8e0ed763ff9f26719830984 upstream. On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using "pci-host-cam-generic" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. Fixes: 8fe55ef23387 ("PCI: Dynamically map ECAM regions") Signed-off-by: Steffen Persvold [mani: removed timestamp from log] Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260709122446.3151899-1-spersvold@gmail.com Signed-off-by: Greg Kroah-Hartman commit 159d162fe80bd56573cafde5801bd5a90a3dd1ac Author: Darrick J. Wong Date: Sun Aug 23 20:09:32 2026 -0400 xfs: don't livelock in scrub on a circular unlinked list [ Upstream commit 527eaaefddb6ec5c83a06c9a1559960dd6361753 ] LOLLM points out that online fsck can livelock if an unlinked inode list contains a loop. Use a bitmap to detect cycles. Cc: stable@vger.kernel.org # v4.15 Fixes: a12890aebb8959 ("xfs: scrub the AGI") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a05a1b663464bda40bb1aeb9e4775b498f46d008 Author: Darrick J. Wong Date: Sun Aug 23 20:09:31 2026 -0400 xfs: hoist per-bucket unlinked list check to helper [ Upstream commit 7cdafd8f10ebdf745ba6046b9fa67490c343a17f ] In the next patch we're going to make this loop more exciting, so hoist the code to a helper function to reduce clutter in the resulting code. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Stable-dep-of: 527eaaefddb6 ("xfs: don't livelock in scrub on a circular unlinked list") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d678be8e58e922c669c64530a94302599c114d0 Author: Darrick J. Wong Date: Sun Aug 23 20:09:20 2026 -0400 xfs: rtsummary scrub should treat rtbitmap corruption errors as an xref error [ Upstream commit 8ed78104722b57df69478b0b1608a408c1036085 ] LOLLM notes the discrepancy between the comment saying that this is an xref error and the code, which marks a (non-xref) corruption error. This appears to be a regression. Cc: stable@vger.kernel.org # v6.13 Fixes: e3088ae2dcae3c ("xfs: move RT bitmap and summary information to the rtgroup") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino [ changed `xchk_ip_xref_set_corrupt(sc, rbmip)` to `xchk_ino_xref_set_corrupt(sc, rbmip->i_ino)` since the renamed helper is absent ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 00e2baf0b5ea9c168580309f549a50652d6927fc Author: Christoph Hellwig Date: Sun Aug 23 20:09:19 2026 -0400 xfs: add a xchk_ip_set_corrupt helper [ Upstream commit aa7cfdb6e16b474328c79736f9b9dad09addc81c ] Add a smaller wrapper to set a inode corrupted by the xfs_inode pointer. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Stable-dep-of: 8ed78104722b ("xfs: rtsummary scrub should treat rtbitmap corruption errors as an xref error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 755d0b7ee356313f769de43000a26eaa29a6abd2 Author: Luca Fresi Date: Thu Aug 20 18:28:01 2026 -0400 serial: sc16is7xx: enable THRI before filling TX FIFO [ Upstream commit 246ac114f485c2affb454240f3ea4fabfce22456 ] sc16is7xx_handle_tx() currently requests the THRI enable only after it has filled the TX FIFO. The request is asynchronous because the IER update is performed later by reg_work. The SC16IS7xx generates a THRI interrupt when the TX FIFO crosses its trigger level. If the FIFO drains past that level before reg_work enables THRI, the chip does not generate a new interrupt. Characters remain queued indefinitely even though the hardware FIFO is empty. This was observed on an SC16IS752 while both UART channels were active. During the stall the software TX buffer remained non-empty while TXLVL reported 64 bytes free, LSR reported THR and transmitter empty, IER had THRI enabled, and IIR reported no interrupt pending. Enable THRI synchronously before filling the FIFO so the threshold crossing cannot be missed. Fixes: cc4c1d05eb10 ("sc16is7xx: Properly resume TX after stop") Cc: stable Signed-off-by: Luca Fresi Link: https://patch.msgid.link/20260721222404.204746-1-luca.fresi@bithiatec.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5a12344a043e0908dc8fa13580c9a61c487e043 Author: Hugo Villeneuve Date: Thu Aug 20 18:28:00 2026 -0400 serial: sc16is7xx: use guards for simple mutex locks [ Upstream commit 0f4f88bfd7e7bf3f3293045fffdc63586b0a889f ] Guards can help to make the code more readable, so use them wherever they do so. In sc16is7xx_port_irq(), labels and 'rc' locals are eliminated completely. Signed-off-by: Hugo Villeneuve Link: https://patch.msgid.link/20251027142957.1032073-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 246ac114f485 ("serial: sc16is7xx: enable THRI before filling TX FIFO") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 450fe8f6f1f8cff6ab0f9e95a863f4c3614a1e3f Author: Hugo Villeneuve Date: Thu Aug 20 18:27:59 2026 -0400 serial: sc16is7xx: rename EFR mutex with generic name [ Upstream commit d9b2d7ddbb973b981c20b21e9228581bb156f66f ] This mutex is used as a lock when accessing registers that share the same address space, not necessarily EFR registers. For example, address 0x06 is shared by MSR, TCR and XOFF1 registers, independently of EFR. Rename the mutex with a more generic name to avoid misinterpreting its usage. Signed-off-by: Hugo Villeneuve Link: https://patch.msgid.link/20251027142957.1032073-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 246ac114f485 ("serial: sc16is7xx: enable THRI before filling TX FIFO") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d3fea146457beac2a6101620fd7337eb894fc0a4 Author: Alexandre Frade Date: Tue Aug 25 17:13:10 2026 +0000 Linux 6.18.46-xanmod1 Signed-off-by: Alexandre Frade commit 8c0d3dba26dce47e260a4d980c9dfe981f3035d2 Merge: e1e49f488a1c 1f99e9ab748f Author: Alexandre Frade Date: Tue Aug 25 17:06:23 2026 +0000 Merge tag 'v6.18.46' into 6.18 This is the 6.18.46 stable release commit 1f99e9ab748fc5c32120de9c4eca31abfe54a4d5 Author: Greg Kroah-Hartman Date: Sun Aug 23 14:27:10 2026 +0200 Linux 6.18.46 Link: https://lore.kernel.org/r/20260820145237.531699751@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Barry K. Nathan Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b7ce4b3bc1068f90debd2a3aeef84753dffbeb78 Author: Ajrat Makhmutov Date: Sat Aug 8 21:55:00 2026 +0300 ALSA: hda/realtek: Enable headset mic on F+ FLAPTOP r [ Upstream commit 7097666b993b37f4e47982026b703b2379a364f8 ] The BIOS of the F+ FLAPTOP r laptop (Realtek ALC897, SSID 1e63:6d9a) declares only pin 0x1b, the headphone output of the 3.5 mm combo jack. Every other external pin is left at 0x411111f0, so the headset mic pin 0x19 is never parsed and no headset mic input exists. The pin is wired on this board - retasking it makes the headset mic record. Reuse ALC897_FIXUP_HP_HSMIC_VERB, which already sets the pin config this machine needs: 0x19 as a headset mic without its own presence detect. Only 0x1b reports jack presence here, so a mic pin with presence detect would leave the driver in auto-mic mode waiting for an event that never arrives. Without the quirk the generic parser retasks the lone headphone pin as an input instead. That surfaces as a "Headphone Mic" input which records only the internal mic bleed, so the headset mic appears present but dead. Tested on ALT Linux, kernel 6.12, by recording a CTIA headset mic on the combo jack with the internal mic as a reference. ALSA info before the patch: https://alsa-project.org/db/?f=18363eddea933baee100c9bf461d0e5cf74c8de2 ALSA info after the patch: https://alsa-project.org/db/?f=48ae2cd7aaf1eb0f24639ce83cd38cfd93b25f76 Cc: stable@vger.kernel.org # 6.12.x Signed-off-by: Ajrat Makhmutov Link: https://patch.msgid.link/20260808185500.2564948-1-rauty@altlinux.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 192f44513a03b624d0f25c97acb9ca93ce6eda09 Author: Takashi Sakamoto Date: Sat Feb 28 11:56:03 2026 +0900 firewire: ohci: initialize page array to use alloc_pages_bulk() correctly commit 9197e5949a41cfb5d44a6b8a860766266340d558 upstream. The call of alloc_pages_bulk() skips to fill entries of page array when the entries already have values. While, 1394 OHCI PCI driver passes the page array without initializing. It could cause invalid state at PFN validation in vmap(). Fixes: f2ae92780ab9 ("firewire: ohci: split page allocation from dma mapping") Reported-by: John Ogness Reported-and-tested-by: Harald Arnesen Reported-and-tested-by: David Gow Closes: https://lore.kernel.org/lkml/87tsv1vig5.fsf@jogness.linutronix.de/ Signed-off-by: Takashi Sakamoto Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e5e6ce7009a6cc65029f52241ca967af77b3568f Author: Thomas Zimmermann Date: Tue Nov 4 11:36:04 2025 +0100 drm/vmwgfx: Set surface-framebuffer GEM objects commit 9942d36a73c2d46c52fdd6f37cf698f3cb09ce5c upstream. Set struct drm_framebuffer.obj[0] to the allocated GEM buffer object for surface framebuffers. Avoids a NULL-pointer deref in the client's vmap helpers. [ 22.640191] Console: switching to colour frame buffer device 160x50 [ 22.641788] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001f: 0000 [#1] SMP KASAN NOPTI [ 22.641795] KASAN: null-ptr-deref in range [0x00000000000000f8-0x00000000000000ff] [...] [ 22.641809] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.24928539.B64.2508260915 08/26/2025 [ 22.641812] Workqueue: events drm_fb_helper_damage_work [ 22.641824] RIP: 0010:drm_gem_lock+0x25/0x50 [ 22.641831] Code: 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 53 48 89 fb 48 81 c7 f8 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b bb f8 00 00 00 31 f6 5b e9 16 2e 15 01 e8 [...] [ 22.641889] Call Trace: [ 22.641891] [ 22.641894] drm_client_buffer_vmap_local+0x78/0x140 [ 22.641903] drm_fbdev_ttm_helper_fb_dirty+0x20c/0x510 [drm_ttm_helper] [ 22.641913] ? __pfx_drm_fbdev_ttm_helper_fb_dirty+0x10/0x10 [drm_ttm_helper] [ 22.641918] ? __raw_spin_lock_irqsave+0x8c/0xf0 [ 22.641924] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 [ 22.641928] ? __pfx_mutex_lock+0x10/0x10 [ 22.641936] drm_fb_helper_fb_dirty+0x29a/0x5e0 [ 22.641942] ? __pfx_drm_fb_helper_fb_dirty+0x10/0x10 [...] Signed-off-by: Thomas Zimmermann Fixes: ea39f2e66e61 ("drm/client: Deprecate struct drm_client_buffer.gem") Reported-by: Ian Forbes Closes: https://lore.kernel.org/dri-devel/CAO6MGtjg8PiRiSLomJQRBduTBSC0WkqX67tEZwA9qwOgRzchpw@mail.gmail.com/ Cc: Thomas Zimmermann Cc: Jocelyn Falempe Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Tested-by: Ian Forbes Reviewed-by: Jocelyn Falempe Reviewed-by: Zack Rusin Link: https://patch.msgid.link/20251104103611.167821-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 7e351209dc2f447e854b9e4a221f7327dd8c52b7 Author: Gao Xiang Date: Wed Aug 12 21:11:43 2026 +0800 erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms [ Upstream commit a64d500b0078e16e9abb25baca4dee1dbc9054fc ] CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this can cause make oldconfig to loop indefinitely when CONFIG_SMP=n: $ make ARCH=arm allmodconfig $ sed -i "/CONFIG_SMP=y/d" .config $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) ... Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS depend on SMP"). The initial report from SJ Park was for m68k [1] (m68k is the only arch without NR_CPUS in Kconfig), and that got fixed in commit 1fd495ef09ee ("m68k: Define NR_CPUS to 1") Reported-by: SJ Park Link: https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u [1] Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org Reported-by: Guenter Roeck Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Gao Xiang Tested-by: SJ Park Tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 67ac7e01c26be30e6427f644045b26f08ff2243d Author: Jasper Wise Date: Thu Aug 13 08:46:18 2026 +0000 spi: virtio: mark device ready before registering the controller [ Upstream commit 11058bd3d47d57eb3473935feae53868d6d168b7 ] virtio_spi_probe() registers the SPI controller with devm_spi_register_controller(). spi_register_controller() binds a child inline unless its driver has asked for asynchronous probing, so a peripheral that performs a transfer during its own probe reaches virtio_spi_transfer_one(), which kicks the virtqueue before probe has returned. The driver never calls virtio_device_ready(), so DRIVER_OK is set on its behalf by virtio_dev_probe(), only once probe has returned. The virtio spec is explicit about that ordering in 3.1 Device Initialization: | The driver MUST NOT send any buffer available notifications to the | device before setting DRIVER_OK. A device that waits for DRIVER_OK before servicing the queue therefore leaves the transfer unanswered, and virtio_spi_transfer_one() waits for its completion with no timeout, so probe never returns. Mark the device ready before registering the controller, as done for the same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and commit 1d774589f924 ("i2c: virtio: mark device ready before registering the adapter"). Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Signed-off-by: Jasper Wise Link: https://patch.msgid.link/20260813084618.613172-1-jaspwise@amazon.co.uk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a7d172b27aa3e1ad56e39949bfe4e5caa25fb20b Author: Shixiong Ou Date: Wed Jul 29 16:48:15 2026 +0800 drm/log: Fix infinite loop when scale is too large for display [ Upstream commit f4f2bba28df9b9aaa00262a462139dbbcdc38d9f ] When scale is large enough that scaled_font exceeds the display dimensions, rows or columns become 0. A columns value of 0 causes an infinite loop in drm_log_draw_kmsg_record() because the loop never decrements len. Check for zero rows/columns in drm_log_setup_modeset() and return an error, cleaning up the already allocated buffer to avoid a leak. Fixes: 8a4b913df427 ("drm/log: Add integer scaling support") Signed-off-by: Shixiong Ou Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260729084815.692944-1-oushixiong1025@163.com Signed-off-by: Jocelyn Falempe Signed-off-by: Sasha Levin commit a6325e2807dc2b985a2fea363794e0ed52e02698 Author: Thomas Zimmermann Date: Mon Oct 27 13:09:16 2025 +0100 drm/client: Remove drm_client_framebuffer_delete() [ Upstream commit 3e3153325fd3693d0f9fe235c4afbcd68ef102e1 ] Release client buffers with drm_client_buffer_delete() instead of drm_client_framebuffer_delete(). The latter is just a tiny wrapper around the former. Move the test for !buffer into drm_client_buffer_delete(), although all callers appear to always have a valid pointer. v2: - test for !buffer before deref-ing pointer (Jocelyn, Dan) Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Francesco Valla Link: https://patch.msgid.link/20251027121042.143588-6-tzimmermann@suse.de Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display") Signed-off-by: Sasha Levin commit 329731b3119f0cd3fe68f650f844462dad4895e8 Author: Thomas Zimmermann Date: Mon Oct 27 13:09:15 2025 +0100 drm/client: Deprecate struct drm_client_buffer.gem [ Upstream commit ea39f2e66e61035e203530977a3df428345d03e2 ] The client buffer's framebuffer holds a reference and pointer on each of its GEM buffer objects. Thus the field gem in the client- buffer struct is not necessary. Deprecated the field and convert the client-buffer helpers to use the framebuffer's objects. In drm_client_buffer_delete(), do a possible vunmap before releasing the framebuffer. Otherwise we'd eventually release the framebuffer before unmaping its buffer objects. v2: - avoid dependency on CONFIG_DRM_KMS_HELPER Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Francesco Valla Link: https://patch.msgid.link/20251027121042.143588-5-tzimmermann@suse.de Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display") Signed-off-by: Sasha Levin commit 0763282e689e2a5b49c1d20b248d138030622883 Author: Thomas Zimmermann Date: Mon Oct 27 13:09:14 2025 +0100 drm/client: Inline drm_client_buffer_addfb() and _rmfb() [ Upstream commit 7cc0f6171b9f93da2815d95d4410f14583cba58f ] Creating and deleting a client buffer always creates and deletes the underlying DRM framebuffer. Inline the helper functions into their callers. With the _addfb code being inlined into drm_client_buffer_create(), clean up the function's error rollback to release the framebuffer's handle and GEM buffer object as needed. Move the _rmfb code into drm_client_buffer_delete() rather than its current location in drm_client_framebuffer_delete(). The former is now the inverse of drm_client_buffer_create(). Makes no difference for cleaning up. Also prepares for the removal of drm_client_framebuffer_delete(). Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Francesco Valla Link: https://patch.msgid.link/20251027121042.143588-4-tzimmermann@suse.de Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display") Signed-off-by: Sasha Levin commit 60f1a2ecdf8b958f0bec81e1b9886ec9d8d85ff3 Author: Thomas Zimmermann Date: Mon Oct 27 13:09:13 2025 +0100 drm/client: Move dumb-buffer handling to drm_client_framebuffer_create() [ Upstream commit 2d262a483c7a128e50cdb64a0ec20c6d78df66cc ] Dumb-buffer creation within the client code is asymetrically balanced across drm_client_buffer_create() and drm_client_framebuffer_create(). Put all dumb-buffer code into drm_client_framebuffer_create() and leave client-buffer initialization to drm_client_buffer_create(). Clarifies responsibility between these functions. Apart form the architectural improvements, drm_client_buffer_create() can now be exported if needed by clients. The client will be able to initialize buffers that have been created from other interfaces than dumb buffers. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Francesco Valla Link: https://patch.msgid.link/20251027121042.143588-3-tzimmermann@suse.de Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display") Signed-off-by: Sasha Levin commit 841bc853a2b115457d980891a44e64c5122f7bca Author: Thomas Zimmermann Date: Mon Oct 27 13:09:12 2025 +0100 drm/client: Remove pitch from struct drm_client_buffer [ Upstream commit dce4657ff526b65007fe8d5c92968a933cc7c9da ] Only the client-buffer setup uses the pitch field from struct drm_client_buffer. Remove the field and pass the value among setup helpers. Clients that need the pitch should rather look at the framebuffer's pitches[0] directly. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Francesco Valla Link: https://patch.msgid.link/20251027121042.143588-2-tzimmermann@suse.de Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display") Signed-off-by: Sasha Levin commit 16a2716910ecf7d31bf3c033ee7c506a0b00b2ee Author: Shixiong Ou Date: Wed Jul 29 16:45:17 2026 +0800 drm/log: Fix out-of-bounds read on empty message length [ Upstream commit 60baa179ed1333535f6e2da4133511db55278ee4 ] drm_log_draw_kmsg_record() accesses s[len - 1] to strip the trailing newline, but len is unsigned int. If len is 0, the subtraction wraps to UINT_MAX, causing an out-of-bounds read. Add an early return when len is 0. Fixes: 25e2c2a3eff5 ("drm/log: Color the timestamp, to improve readability") Signed-off-by: Shixiong Ou Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260729084520.688087-1-oushixiong1025@163.com Signed-off-by: Jocelyn Falempe Signed-off-by: Sasha Levin commit 948f346fe36e1d02353c3d61b1f6b66c6af91996 Author: Linmao Li Date: Fri Jul 31 09:19:32 2026 +0800 drm/xe/oa: Fix sync entry leak on OA config emit failure [ Upstream commit 8d33c4987cd162527375a3905017ae129ba7c3fe ] xe_oa_emit_oa_config() releases the sync entries and the syncs array only on its success path. When it fails before the point of no return (fence allocation, config buffer allocation or batch submission), it returns without touching stream->syncs. The stream open path handles such failures in the caller, but xe_oa_config_locked() propagates the error without any cleanup, so the syncs array and the fence references held by the parsed entries are leaked. The next config ioctl overwrites stream->syncs, making the memory unreachable for good. Clean up the parsed syncs when xe_oa_emit_oa_config() fails, matching the cleanup done by the stream open error path. Fixes: 9920c8b88c5c ("drm/xe/oa: Add syncs support to OA config ioctl") Signed-off-by: Linmao Li Reviewed-by: Ashutosh Dixit Signed-off-by: Ashutosh Dixit Link: https://patch.msgid.link/20260731011932.3426219-1-lilinmao@kylinos.cn (cherry picked from commit 8af97b3da2cfce04e6b457c6eb17ed3c1daf912b) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit ed5470771c7ed7f959230c4697f316af83426a90 Author: Aleksandr Nogikh Date: Fri Aug 7 14:25:26 2026 +0000 firewire: ohci: fix NULL pointer dereference in ar_context_release [ Upstream commit 42d217add8d80d6e7d9f58f80d11ea9b07ea113e ] During the error handling path of the driver's probe function, a NULL pointer dereference can occur in ar_context_release(). When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping fails), the devres cleanup mechanism invokes release_ohci(). This function unconditionally calls ar_context_release() to clean up the asynchronous receive contexts. However, if ar_context_init() was not yet called, ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by devres_alloc()). ar_context_release() immediately dereferences ctx->ohci to get the dev pointer before checking if the context was actually initialized, leading to a crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543 Call Trace: release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567 release_nodes drivers/base/devres.c:546 [inline] devres_release_all+0x1a8/0x260 drivers/base/devres.c:576 device_unbind_cleanup drivers/base/dd.c:597 [inline] really_probe+0x451/0xae0 drivers/base/dd.c:772 To fix this, move the assignment of the dev pointer after the !ctx->buffer check. If ctx->buffer is NULL, it indicates that the context was never successfully initialized and there is nothing to release, safely avoiding the dereference of the uninitialized ctx->ohci pointer. Fixes: 5716e58aecdd ("firewire: ohci: release buffer for AR req/resp contexts when managed resource is released") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+d30aad27833a559defab@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d30aad27833a559defab Link: https://syzkaller.appspot.com/ai_job?id=10a18617-7893-42dd-bf1c-cd49e19e95d9 Signed-off-by: Aleksandr Nogikh Link: https://lore.kernel.org/r/90c5db71-dd1f-4d46-b9d3-2f1046cbd5ea@mail.kernel.org Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 384d9f04b38f490d016ce90dd982d8bbc5ab35a9 Author: Takashi Sakamoto Date: Sat Jan 10 10:39:10 2026 +0900 firewire: ohci: split page allocation from dma mapping [ Upstream commit f2ae92780ab93ed7e59e469cfd5c7269bd68ddb4 ] 1394 OHCI PCI driver had long been the only user of dma_alloc_pages(). Although tee subsystem recently started using it, they are still a few users of the infrequently-used function. In the discussion for dma-mapping function, Jason Gunthorpe shows his opinion about the design of public API for the function. According to it, the users provide physical address to the function, then receive DMA mapping address, regardless of the location of mapping target. With the above aspects, this commit eliminates the use of dma_alloc_pages() from this subsystem. Link: https://lore.kernel.org/lkml/20250905174324.GI616306@nvidia.com/ Link: https://lore.kernel.org/r/20260110013911.19160-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 42d217add8d8 ("firewire: ohci: fix NULL pointer dereference in ar_context_release") Signed-off-by: Sasha Levin commit adb3e7c26a51a10d94a241c6de7a81a2863dcacf Author: Jamal Hadi Salim Date: Sun Aug 9 05:44:18 2026 -0400 net/sched: cls_bpf: reject dev-bound programs bound to a different device [ Upstream commit 120977e2c096deea4e866e4273be9220b957c29e ] cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Acked-by: Daniel Borkmann Link: https://patch.msgid.link/20260809094418.901607-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1f493c44a2f04e9bb64043aa632a4ccaf237ec66 Author: Lizhi Hou Date: Wed Aug 12 13:56:28 2026 -0700 accel/amdxdna: Skip unmapped range in aie2_populate_range() [ Upstream commit 6c916e301fa10de9158b922474ade7b43d726cda ] aie2_populate_range() incorrectly failed jobs for BOs with multiple mmaps: if the unmapped entry appeared first in umap_list, the loop would pick it up, call hmm_range_fault() on a gone VMA, and return -EFAULT without ever trying the remaining valid mapps. Fix it by skipping unmapped entries. After the loop, if the map list is empty or all maps are valid, map_invalid can be cleared normally. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260812205628.810816-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 72e4e3d7efc3b7d85f86abbe8b94f8e45074abe3 Author: Siddharth Vadapalli Date: Fri Aug 7 16:47:37 2026 +0530 net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG [ Upstream commit 36a05d2820077bb3955acb8111e1041d39148037 ] On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Siddharth Vadapalli Reviewed-by: Chintan Vankar Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6cf600b276a55a6481462830607a611f32e737c0 Author: Andrey Golovko Date: Tue Aug 11 22:14:35 2026 +0300 regmap: sdw-mbq: don't call an unset readable_reg callback [ Upstream commit 00268f9452d2a0d660aa9c1bb0ca07a994af6a4f ] regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit by calling ctx->readable_reg(), which is a straight copy of config->readable_reg. That callback is optional: regmap_readable() treats a NULL ->readable_reg as "every register is readable", and drivers rely on that. es9356 and tac5xx2-sdw both build an MBQ regmap without one. Since commit ca1b11b36d82 ("regmap: sdw-mbq: Allow defers on undeferrable controls") the poll runs on every -ENODATA, not only for Controls the driver marked deferrable, so any of those devices answering COMMAND_IGNORED takes the kernel through a NULL function pointer. Treat a missing callback the way the rest of regmap does and poll. Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls") Signed-off-by: Andrey Golovko Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260811184500.5312-1-andrey.golovko@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c27eed546ae204032fa30a70636b5897c2e4c4f8 Author: Uwe Kleine-König Date: Fri Jul 31 11:49:49 2026 +0200 m68k: Define NR_CPUS to 1 [ Upstream commit 1fd495ef09eef96169a379a749c24b5e69974bb8 ] This fixes a Kconfig warning fs/erofs/Kconfig:137:warning: range is invalid which originates from EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS using NR_CPUS which up to now didn't exist for ARCH=m68k. All other architectures define this symbol, so fix the outlier. [geert] This also fixes: - CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS being set to the literal NR_CPUS instead of a number by automatic configs like "make allmodconfig" or "make olddefconfig", - An infinite loop in manual configs like "make oldconfig" when CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is not present or has an invalid value in your existing .config. Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Uwe Kleine-König Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260731094950.1988084-2-ukleinek@kernel.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 31f26a95eeee926946809ac456c61a3217936a62 Author: Zhang Changzhong Date: Fri Aug 7 15:50:38 2026 +0800 net/sched: cls_u32: skip hash tables in u32_bind_class() [ Upstream commit 6d3724e616faf952c3adcf8414fc21a828ef3709 ] u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check. Fixes: 07d79fc7d94e ("net_sched: add reverse binding for tc class") Signed-off-by: Zhang Changzhong Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/1786089038-36366-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abceabc4408fca6a9dd52611f5d197dec9390d63 Author: Jamal Hadi Salim Date: Sun Aug 9 05:09:28 2026 -0400 net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain [ Upstream commit f60b396ee174206fe08ebf997d16cd3801b77b22 ] tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value. Fixes: ee3bbfe806cd ("net/sched: let actions use RCU to access 'goto_chain'") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Davide Caratti Link: https://patch.msgid.link/20260809090928.868186-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98c5914d6b7bd4b4675535908e57dea31f1efd6a Author: Eric Dumazet Date: Mon Aug 10 15:04:47 2026 +0000 af_packet: Don't send zero-byte data in tpacket_snd(). [ Upstream commit 6bcd76c134c55c697148acb5c0194e9666abdf84 ] syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") and in packet_sendmsg_spkt() via commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+30b93b6845b19cc38581@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a79e807.01d0871a.3a0d52.00ac.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260810150447.1220864-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37c5ccaaacd48aa4056dc51dc90b8561fd2cea2f Author: Charles Keepax Date: Tue Aug 11 14:18:16 2026 +0100 regmap: sdw-mbq: Fix swap of timeout and retry times [ Upstream commit ae7fd6ff4c6713270d2efe6db87a4a58ccb7cc61 ] When polling Function Busy using read_poll_timeout() the total timeout and retry delay arguments are swapped. This leads to only a single retry being processed, it seems the existing users typically do succeed before the first retry. Swap the arguments over to ensure the correct polling time. Reported-by: Ville Saarinen Link: https://lore.kernel.org/linux-sound/ansTPGgVNoDJlA5r@opensource.cirrus.com/T/#m680731a2f307f1f5176b27ed5aa560ddc94e5d62 Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260811131816.332082-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f51a540b14eecb8667bbe450192318271b87631e Author: Rosen Penev Date: Thu Aug 6 16:32:31 2026 -0700 ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers [ Upstream commit f12afefb7b01f94d6d66d397f323a9914edbf70e ] The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash. Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect. Fixes: 6f6c3c36f091 ("ASoC: xlnx: add pcm formatter platform driver") Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Rosen Penev Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260806233231.30631-1-rosenp@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 82d9269f01ebfd835b6256aa17016a974cbbc647 Author: Chuck Lever Date: Thu Aug 6 20:44:07 2026 -0400 net/tls: Fail tls_sw_splice_read() after a failed async decrypt [ Upstream commit 976df67f463db1fddaf2a32fb04f57ad2891a23d ] When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do. Fixes: f314bfee81b1 ("tls: rx: return the already-copied data on crypto error") Reviewed-by: Jakub Kicinski Signed-off-by: Chuck Lever Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260806-tls-splice-crypto-fix-v1-1-a2624005a286@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cef4c5b9aca24651d069adf9462b221df6a2a669 Author: Jiawen Wu Date: Fri Aug 7 14:22:14 2026 +0800 net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling [ Upstream commit 5f3a13e0bb5ebcc1ca2dfda42ea40b9f3c2be6ea ] In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences wx->msix_entry->entry, leading to a NULL pointer dereference crash. This issue was introduced by fixing the IRQ vector when the number of VFs is 7. Fix the issue by explicitly checking `pdev->msix_enabled` to determine the correct vector index. Additionally, as a side fix, set the interrupt mask to BIT(0) for the non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts share vector 0, and the WX_PX_MISC_IVAR register is only valid in the MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause when MSI-X is disabled. Fixes: 4174c0c331a2 ("net: ngbe: specify IRQ vector when the number of VFs is 7") Signed-off-by: Jiawen Wu Reviewed-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/B2693E9A8BFAD110+20260807062214.410838-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5ffaa5d7f56ab24a8e23cf131eadfef31a3bbc4b Author: Wei Fang Date: Fri Aug 7 14:34:05 2026 +0800 net: tap: fix wrong transport_header when sending VLAN-tagged frame [ Upstream commit cbb35cbe8db268fefe34c23df15348cf99025298 ] In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g. ETH_P_8021Q), skb_set_network_header() is called first to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to ETH_P_8021Q, while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_set_network_header() to after skb_probe_transport_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the flow dissector can parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly. Fixes: 8c76e77f9069 ("tap: call skb_probe_transport_header after setting skb->dev") Assisted-by: WChat:claude-opus-4-8 Signed-off-by: Wei Fang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260807063405.688780-3-wei.fang@oss.nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f9297abbcaba760b7a7b9d63b839f607f738013e Author: Wei Fang Date: Fri Aug 7 14:34:04 2026 +0800 net: packet: fix wrong transport_header when sending VLAN-tagged frame [ Upstream commit 01fdecc0480d916c799dbee584833a4a37e94d06 ] In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to the outer VLAN EtherType (e.g. ETH_P_8021Q), while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly. Fixes: dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO") Assisted-by: WChat:claude-opus-4-8 Signed-off-by: Wei Fang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260807063405.688780-2-wei.fang@oss.nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0af3afd054e7bfefc2179c0e717b2f9bbd911b94 Author: Oleksij Rempel Date: Thu Aug 6 15:47:16 2026 +0200 net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path [ Upstream commit 202fef9bbbf5784487eec27581389c6fb97c350d ] In rtlgen_write_mmd(), the MDIO_AN_EEE_ADV case swaps the arguments to rtlgen_write_vend2(): it passes the MMD register number as the OCP address and the OCP address constant as the value. The caller's value is discarded and the write lands on the wrong register, so the EEE advertisement cannot be configured on the affected PHYs. Mirror rtlgen_read_mmd() and write the value to RTL_MDIO_AN_EEE_ADV. Fixes: da681ed73fb9 ("net: phy: realtek: improve mmd register access for internal PHY's") Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260806134716.3511821-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17e3181d740d1027c3de4a030267115dc1b3b53a Author: Jiayuan Chen Date: Fri Aug 7 09:44:36 2026 +0800 tcp: fix icsk_ack.ato bitfield overflow [ Upstream commit 60837e4b840a9c3f7ec826e3584df0bc6542a2c2 ] On cross-region connections we observed delayed ACKs suddenly turning into immediate ACKs plus a TCP_MAX_QUICKACKS burst, as if the connection had just received its first data segment. Commit 95b9a87c6a6b ("tcp: record last received ipv6 flowlabel") squeezed icsk_ack.ato into 8 bits, sized for TCP_DELACK_MAX. But both writers still bound ato by icsk_rto, which can be well above 255 jiffies, so the bitfield assignment silently wraps mod 256: repeated delack timer misses double ato up to icsk_rto, storing 320 as 64 and 256 as 0, and ato == 0 is the "first data packet" sentinel in tcp_event_data_recv(). Clamp both writers to TCP_DELACK_MAX, which the static_assert already guarantees to fit and tcp_send_delayed_ack() effectively caps ato at anyway. Fixes: 95b9a87c6a6b ("tcp: record last received ipv6 flowlabel") Signed-off-by: Jiayuan Chen Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20260807014437.36687-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 73f8dd22b1e533a99ecc3f9b5de6c6daccaecace Author: Jonas Köppeler Date: Thu Aug 6 13:43:49 2026 +0200 veth: fix queue index used to wake the peer txq in veth_poll [ Upstream commit 60db47f02bfa2aa688938aa199117ec4f8e31d23 ] veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") Signed-off-by: Jonas Köppeler Tested-by: Jesper Dangaard Brouer Acked-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/20260806-veth-fix-poll-queue-idx-v1-1-c5357fb7573d@tu-berlin.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96fa90b74385b7f2b0d97251dd43d5ee6ca44668 Author: Eric Dumazet Date: Thu Aug 6 14:19:38 2026 +0000 macvlan: inherit needed_headroom and needed_tailroom from lowerdev [ Upstream commit cef51860becd9700217c81732ca1eb1ea6ed6fe1 ] macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#m16adf0ff972cbfd8066c3a8e656e75eaeb12d021 Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260806141938.287660-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5f33188457bbcc1b11ca87084037963c516ed3d9 Author: Eric Dumazet Date: Thu Aug 6 10:38:57 2026 +0000 ipvlan: inherit needed_headroom and needed_tailroom from phy_dev [ Upstream commit e16e960d55a40d36bd7c2494cc005e757dc9a1ef ] ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Reported-by: syzbot+1f9fd0f4b601cf88d6e6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a720a21.40259c87.584f4.04bb.GAE@google.com/T/#u Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#mcc6307f115e500df23ea2980d5669fe95f20b6b4 Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260806103857.115541-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1072f0f44282011ceb9182fbfcd5c1cdfee13246 Author: Jakub Kicinski Date: Mon Aug 3 12:31:33 2026 -0700 eth: bnxt: keep the aRFS rmap updated when TPH is enabled [ Upstream commit 4b5cb58a4443fff67aa18a0d7b645b2220f2fcf8 ] The TPH support must have broken aRFS in bnxt. IRQ can only have one notifier, so installing the TPH notifier is overriding the one implicitly installed by irq_cpu_rmap_add(). Make sure we call cpu_rmap_update() from the TPH notifier. We need to be careful with the ordering and not free the rmap until we unregistered the notifier. Note that moving the rmap freeing after the early return in bnxt_free_irq() is fine - there's no path that could leave rmap with irq_tbl being NULL. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260803193135.2030368-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 394f1b16c5d1b0ae84bb04a1168493c2cb75a8da Author: Jakub Kicinski Date: Mon Aug 3 12:31:32 2026 -0700 eth: bnxt: cancel IRQ notifier before freeing affinity mask [ Upstream commit c703f62c30f2db7f40ad575f0034636d8a401fac ] bnxt_irq_affinity_notify() copies into irq->cpu_mask. Cancel the notifier before freeing irq->cpu_mask. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260803193135.2030368-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a26a1be1b6541836453a2830504d1b3ec702e6c4 Author: Florian Westphal Date: Thu Aug 6 16:17:50 2026 +0200 netfilter: ipset: let destroy callbacks adjust ext mem size [ Upstream commit 490937b88cb592cc0c5367758edd700fd5abd15c ] For bitmap this change makes no difference, because destructors are called synchronously. List type however calls them via call_rcu() so accounting decrement can happen after list_set_flush() set ext_size to 0. 'set->elements = 0' can be removed for the same reason in the list type case, it calls 'set->elements--' for each element. Fixes: 9e41f26a505c ("netfilter: ipset: Count non-static extension memory for userspace") Suggested-by: Jozsef Kadlecsik Signed-off-by: Florian Westphal Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 29c011b3537d77eefe83be89db03dd2eecab1fb9 Author: Florian Westphal Date: Thu Aug 6 15:53:41 2026 +0200 netfilter: ipset: fix list type element drift bug [ Upstream commit 4cbd69766b35a089664cadb1f613bb85f7ef77a9 ] If list_set_uadd() calls list_set_replace() to swap an expired entry, the element count remains the same, therefore the increment must be elided. Fixes: 702b71e7c666 ("netfilter: ipset: Add element count to all set types header") Link: https://sashiko.dev/#/patchset/20260806101947.2802-1-fw%40strlen.de Signed-off-by: Florian Westphal Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d9d3050a70efe217e73a0751e55fdae6a7092620 Author: Jérémy Jean Date: Sat Aug 8 12:40:02 2026 +0000 netfilter: flowtable: publish GC-visible tuple last [ Upstream commit 2014ac62df9d45bb9a004a043e85df7be09ed780 ] nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.). Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure") Signed-off-by: Jérémy Jean Assisted-by: Codex:gpt-5 Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4a923fe60939a194777bc605036ce2147ab00c9d Author: Alexey Velichayshiy Date: Thu Aug 6 19:11:38 2026 +0300 netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path [ Upstream commit d02f592064347e0c1e0d84f24941ad338838cc48 ] In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug. Trace for example: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // fails to -ENOMEM The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nf_tables transaction processing: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] RIP: 0010:nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Call Trace: nf_tables_commit+0x3bd/0x4bd0 net/netfilter/nf_tables_api.c:8604 nfnetlink_rcv_batch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:579 [inline] nfnetlink_rcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x6cd/0xa00 net/netfilter/af_netlink.c:1340 netlink_sendmsg+0x906/0xe10 net/netfilter/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x155/0x190 net/socket.c:663 ____sys_sendmsg+0x705/0x870 net/socket.c:2379 ___sys_sendmsg+0x100/0x170 net/socket.c:2433 __sys_sendmsg+0xe9/0x1c0 net/socket.c:2462 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Change the condition to WARN_ON_ONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 63b48c73ff56 ("netfilter: nf_tables_offload: undo updates if transaction fails") Signed-off-by: Alexey Velichayshiy Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cb20da33839f28f590c99f16bafaa6151451c0e8 Author: Xiang Mei (Microsoft) Date: Wed Jul 22 22:38:32 2026 +0000 netfilter: ipset: fix refcount race between list:set GC and swap [ Upstream commit 0c88868271653537ed443272dd8e7d13634d214b ] __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 9076aea76538 ("netfilter: ipset: Increase the number of maximal sets automatically") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9e75e7da43740475d690c731e07856cfa62551e7 Author: Shenghao Ding Date: Fri Aug 7 08:03:04 2026 +0800 ASoC: tas2781: fix clang build error for goto bypassing cleanup variable [ Upstream commit 566fec6a33075a0ea5c441c26571221f17f4ed98 ] Remove invalid goto exit paths that jump across guard(mutex) cleanup variable initialization, replace them with direct kfree(src) and return, to fix the s390 clang build error in acoustic_ctl_write(). Fixes: d75d38dc4604 ("ASoC: tas2781: Add a debugfs node for acoustic tuning") Signed-off-by: Shenghao Ding Link: https://patch.msgid.link/20260807000304.826-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 24d0f33f5415ffa8f9f1b16781c94373ded112b8 Author: Junjie Cao Date: Tue Aug 4 17:59:35 2026 +0800 gpio: ml-ioh: share the register lock across channels [ Upstream commit a9253ee6771c8ab3c6de07ea75d9e2c1cef3cd97 ] Suspend and resume hold channel 0's lock while saving and restoring registers for all eight channels. Code paths using the other seven locks can therefore run concurrently with PM. Use one controller-wide lock shared by all channels. Fixes: b490fa0bf86e ("gpio-ml-ioh: Fix suspend/resume issue") Reported-by: sashiko-bot Link: https://lore.kernel.org/r/20260731033956.EE6F61F000E9@smtp.kernel.org Signed-off-by: Junjie Cao Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260804095935.2132215-1-junjie.cao@intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 7a03413f31c196ab3894f988cdce0bb47b4fec42 Author: Kyle Zeng Date: Thu Aug 6 13:56:55 2026 -0700 perf: Reject exited events as group leaders [ Upstream commit fa091f46c3833fb22384f10eade2b4e1e1d0b278 ] perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events. A new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event. Reject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment. [peterz: make the earlier test fully consistent] Fixes: 037a3c43edfb ("perf/core: Detach event groups during remove_on_exec") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260806205655.75722-1-kylebot@openai.com Signed-off-by: Sasha Levin commit 6c85d169eeecc6764737465eef00225348f1ad36 Author: Pu Lehui Date: Sun Aug 2 09:49:29 2026 +0000 riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions [ Upstream commit 2820d227ad4ee70805d693d698437cc3e88d6c3d ] We are frequently hitting the following splat during the riscv bpf selftests: 00000000026dc75a: expected (7c3ff297) but got (00100073) ------------[ ftrace bug ]------------ ftrace failed to modify [] bpf_kfunc_common_test+0x4/0x20 [bpf_testmod] actual: e7:82:c2:ce Updating ftrace call site to call a different ftrace function ftrace record flags: 80100002 (2) expected tramp: ffffffff80043904 ------------[ cut here ]------------ WARNING: kernel/trace/ftrace.c:2278 at ftrace_bug+0x46e/0x4b0, CPU#1: test_progs/98 ... [] ftrace_bug+0x46e/0x4b0 [] ftrace_replace_code+0x16e/0x170 [] ftrace_modify_all_code+0x12e/0x1b8 [] arch_ftrace_update_code+0x14/0x28 [] ftrace_startup+0x14c/0x2a0 [] ftrace_startup_subops+0x584/0x1050 [] register_ftrace_graph+0x4e6/0x1018 [] register_fprobe_ips+0xc66/0x12f8 [] bpf_kprobe_multi_link_attach+0x5d8/0xe68 [] __sys_bpf+0x3d5a/0x47f0 [] __riscv_sys_bpf+0xae/0x168 [] syscall_handler+0x60/0x100 [] do_trap_ecall_u+0x174/0x208 [] handle_exception+0x16c/0x178 After debugging, it can be triggered by similar commands below: ``` echo do_nanosleep > set_ftrace_filter echo function > current_tracer echo 'p do_nanosleep' > kprobe_events echo 1 > events/kprobes/enable echo 'f do_nanosleep' > dynamic_events echo 1 > events/fprobes/enable ``` The reason is that attaching a kprobe to an ftrace-traced function entry replaces its initial auipc insn with ebreak. When ftrace_modify_call later runs, it expects auipc insn, so verification fails and triggers ftrace_bug. The expected auipc logic remains conceptually unchanged, and kprobe single-stepping ensures normal execution. Therefore, if the first insn is ebreak, bypassing the check to continue patching the jalr insn is safe and avoids ftrace failures. Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching") Signed-off-by: Pu Lehui Link: https://patch.msgid.link/20260802094929.3978390-1-pulehui@huaweicloud.com [pjw@kernel.org: fixed reproducer in commit message] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit a3a676495c6419e0cca04d6a67227604e92a3d5a Author: Ralf Lici Date: Wed Jul 29 12:21:44 2026 +0200 ovpn: finish crypto callback cleanup before peer release [ Upstream commit 9e163917a86c6adfbe150e13f4c73653a54616de ] Crypto completion callbacks hold both key-slot and peer references. The peer reference pins the netdev, and dropping the last peer reference can let netdev unregistration and module removal make progress. Do not release that peer reference before the callback has finished its own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can schedule an RCU callback backed by module text after ovpn_cleanup rcu_barrier has already run. The TX error path also freed the remaining skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev lifetime window. Release the key slot and free any remaining skb first, then drop the peer reference as the last callback action. Fixes: 8534731dbf2d ("ovpn: implement packet processing") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit a47a080d06ee9d94dc6a2da0fc2b9beeeedb92b3 Author: Ralf Lici Date: Wed Jul 29 12:21:41 2026 +0200 ovpn: fix NULL dereference when killing missing key [ Upstream commit 41d44ac7a61e2f74453af40d4fe1b82af9ea0ada ] ovpn_crypto_kill_key assumes both crypto slots are populated and dereferences each slot before checking it. That is not guaranteed: a peer can have only one installed key, and the kill path may be asked to remove a key that is not present. Read each slot once while holding the crypto state lock, check for NULL before looking at key_id, and only replace the slot that actually matches. Fixes: 89d3c0e4612a ("ovpn: kill key and notify userspace in case of IV exhaustion") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 99a18e1d979e0fad3aaf9c65ae6696897c1d9869 Author: Vladislav Dronov Date: Tue Jul 21 00:33:31 2026 +0200 crypto: tegra - fix rctx->cryptlen calculation in tegra_gcm_do_one_req() [ Upstream commit 360f2974fcea49c61f6d6f81554741a9eeee7168 ] Perform rctx->cryptlen calculation in tegra_gcm_do_one_req() the same way it is done in tegra_ccm_crypt_init(). The current formulae may lead to a crash if a caller does not call tegra_gcm_setauthsize() and so ctx->authsize remains zero. Then a decrypt operation with incorrect rctx->cryptlen will lead to a write beyound rctx->dst_sg buffer. As a follow-up cleanup delete struct tegra_aead_ctx->authsize field since it appears to be completely unused. Also simplify tegra_ccm_setauthsize() and tegra_gcm_setauthsize() functions respectively. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Vladislav Dronov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3e4bf50c94511db8997a6fe1e90d946249368bc6 Author: Herbert Xu Date: Mon Jul 20 11:34:21 2026 +1000 crypto: ccm - Set rfc4309 maxauthsize from child [ Upstream commit 438f4896f78f69ec73d5f32d2c024193f1223569 ] Set the maxauthsize of rfc4309 using that of the child algorithm. Fixes: 4a49b499dfa0 ("[CRYPTO] ccm: Added CCM mode") Reported-by: Seohyeon Maeng Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d9ecc9787e118b0a715cd4194c279a6b14c570cc Author: Jon Hunter Date: Tue Jul 28 16:50:59 2026 +0100 arm64: tegra: Add EL2 virtual timer interrupt for Tegra194 [ Upstream commit a7c28483fd57dd0e1487024af70622315320774b ] Commit d87773de9efe ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE") updated the ARM arch timer driver to use the virtual timer by default if the CPU is running at EL2 with VHE enabled. If the CPU is running at EL2 with VHE enabled but there is no interrupt provided for the virtual timer, then the following warning is displayed: arch_timer: [Firmware Bug]: VHE-capable CPU without EL2 virtual timer interrupt This warning is observed on Tegra194 platforms. Tegra194 SoC includes NVIDIA Carmel ARM v8.2 CPUs and support an EL2 virtual timer. Fix the above warning by adding the PPI for the EL2 virtual timer interrupt for Tegra194. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit a4e340971fe8ccd245d206db4d43b2a0eec240bd Author: Koichiro Den Date: Thu Aug 6 12:25:37 2026 +0900 NTB: ntb_netdev: Preserve RX queue depth on allocation failure commit d2121faf133ac3bf9531b53a7e21273649a08517 upstream. ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260806032537.3526498-1-den@valinux.co.jp Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08437c5156b0a0ec8d963af54d9f4a1398dd3415 Author: Koichiro Den Date: Fri Mar 6 00:56:36 2026 +0900 net: ntb_netdev: Introduce per-queue context commit ee970634c7773f248a0a27d8a645500371ae5249 upstream. Prepare ntb_netdev for multi-queue operation by moving queue-pair state out of struct ntb_netdev. Introduce struct ntb_netdev_queue to carry the ntb_transport_qp pointer, the per-QP TX timer and queue id. Pass this object as the callback context and convert the RX/TX handlers and link event path accordingly. The probe path allocates a fixed upper bound for netdev queues while instantiating only a single ntb_transport queue pair, preserving the previous behavior. Also store client_dev for future queue pair creation/removal via the ntb_transport API. Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260305155639.1885517-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski Stable-dep-of: d2121faf133a ("NTB: ntb_netdev: Preserve RX queue depth on allocation failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2a7d8fc0fd50e7a2020989d9840cabb74c0282e3 Author: Peter Ujfalusi Date: Thu Jul 30 08:48:22 2026 +0300 ASoC: SOF: ipc4-topology: Refresh copier IPC payload before widget setup commit 0c0e418dbcf0582bf80d8dbfd9b306607c065992 upstream. The ipc_config_data buffer for copier widgets is built once during ipc_prepare (called from sof_pcm_setup_connected_widgets) and cached for reuse. For host copiers this buffer contains the copier_data with gtw_cfg.node_id (host DMA ID). For DAI copiers it additionally includes a dma_config_tlv trailer with stream_id and dma_channel_id for HDA link DMA. On suspend/resume, both host and link DMA streams are released and re-allocated with potentially different stream tags. The underlying copier_data and dma_config_tlv structures are correctly updated by host_config and sdw_hda_dai_hw_params respectively. However, since the widget list (spcm->stream[].list) persists across suspend, sof_pcm_hw_params skips sof_pcm_setup_connected_widgets and ipc_prepare never runs again to rebuild ipc_config_data. The stale cached payload is then sent to firmware with boot-time DMA channel assignments, causing DMA channel conflicts that lead to firmware errors and crashes. Fix this by refreshing copier_data and dma_config_tlv portions of ipc_config_data in sof_ipc4_widget_setup right before the IPC message is sent. This ensures the payload always reflects the current DMA state regardless of whether ipc_prepare ran. For DAI copiers, the gtw_cfg.config_length in copier_data is temporarily inflated to include the TLV size (matching the ipc_config_data layout) before copying, then restored, mirroring what sof_ipc4_prepare_copier_module does when first building the buffer. Fixes: e9c6b118de1a ("ASoC: SOF: make dma_config_tlv be an array") Cc: stable@vger.kernel.org Link: https://github.com/thesofproject/sof/issues/10700 Link: https://github.com/thesofproject/sof/issues/10955 Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730054822.5913-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8c685df5c3b261c42505110965b42f9a754eb9b7 Author: Yang Wang Date: Wed Aug 12 17:54:03 2026 -0400 drm/amd/pm: fix pptable use-after-free [ Upstream commit bb493058c35c8676e48269ab6732688ea733d23c ] amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. Fixes: 1684d3ba4885 ("drm/amd/amdgpu: change pptable output format from ASCII to binary") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2895aeb4327c9f3452ad705f9f303a5b8697934b Author: Yang Wang Date: Wed Aug 12 17:54:02 2026 -0400 drm/amd/pm: adjust the visibility of pp_table sysfs node [ Upstream commit 5de8ce0f3709ad93ca5a579aa45cf1b52d72bc90 ] v1: - make pp_table invisible on VF mode (only valid on BM) - make pp_table invisible on Mi* chips (Not supported) - make pp_table invisible if scpm feature is enabled. v2: move pp_table invisible code logic into amdgpu_dpm_get_pp_table() function. v3: add table buffer pointer check both on powerplay & swsmu. Signed-off-by: Yang Wang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Stable-dep-of: bb493058c35c ("drm/amd/pm: fix pptable use-after-free") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7755be923e325dc300f4b0c3e1ad7e91b28b3cb9 Author: Zhiling Zou Date: Wed Aug 19 07:15:13 2026 -0400 mm/page_table_check: skip special zero mappings [ Upstream commit 8db4bab826ccc9ec10fa41736a48031cd338d392 ] page_table_check_set() and page_table_check_clear() account mappings based on PageAnon(). Shared zero-page PTEs and huge zero PMDs are special mappings, but page_table_check can still account them as file-backed pages. An unprivileged process can populate enough zero mappings to overflow file_map_count and hit the existing BUG_ON(). The PTE path can do this with the shared zero page, and the PMD path can do the same with huge zero mappings. Skip special zero mappings in the user page-table accounting paths. Keep the PTE-side pte_special() check, and identify huge zero PMDs from the mapped folio instead of pmd_special(). That covers architectures where pmd_special() is a no-op without adding huge_zero_pfn checks to the generic counter helpers. Link: https://lore.kernel.org/cover.1784717203.git.zhilinz@nebusec.ai Link: https://lore.kernel.org/e94478e4fb7912fb7e8ebebed5ce85d00dc9a69d.1784717203.git.zhilinz@nebusec.ai Fixes: df4e817b7108 ("mm: page table check") Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Reported-by: Vega Cc: Pasha Tatashin Assisted-by: Codex:gpt-5.4 Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ae625d16eefb15b20088f7e0fd6016f17135e83 Author: Vincent Donnefort Date: Wed Aug 19 07:14:36 2026 -0400 ring-buffer: Prevent resizing of persistent ring buffer [ Upstream commit 7c727dfce6be04dd009b29091a4a17d952dbfe03 ] Dynamically resizing a persistent ring buffer is not possible. Disable the feature. Cc: stable@vger.kernel.org Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()") Link: https://patch.msgid.link/20260806211306.3704194-2-vdonnefort@google.com Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt [ dropped the incoming `else if (buffer->remote)` block since 6.18 has a plain `else` arm ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 54fc67500ad1b033376fa705d20ddc89bb5197ac Author: Vincent Donnefort Date: Wed Aug 19 07:14:35 2026 -0400 ring-buffer: Store bpage pointers into subbuf_ids [ Upstream commit e682207bf7ae3f81885f612ada1ac44d027158d4 ] The subbuf_ids field allows to point to a specific page from the ring-buffer based on its ID. As a preparation or the upcoming ring-buffer remote support, point this array to the buffer_page instead of the buffer_data_page. Link: https://patch.msgid.link/20260309162516.2623589-3-vdonnefort@google.com Reviewed-by: Steven Rostedt (Google) Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 7c727dfce6be ("ring-buffer: Prevent resizing of persistent ring buffer") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27d7fcaf237df8d74771b8449f9c0ebf5e7755d8 Author: Steven Rostedt Date: Wed Aug 19 07:14:34 2026 -0400 ring-buffer: Add helper functions for allocations [ Upstream commit b1e7a590a0133606d3efd41aee38cdeac630b52f ] The allocation of the per CPU buffer descriptor, the buffer page descriptors and the buffer page data itself can be pretty ugly: kzalloc_node(ALIGN(sizeof(struct buffer_page), cache_line_size()), GFP_KERNEL, cpu_to_node(cpu)); And the data pages: page = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO, order); if (!page) return NULL; bpage->page = page_address(page); rb_init_page(bpage->page); Add helper functions to make the code easier to read. This does make all allocations of the data page (bpage->page) allocated with the __GFP_RETRY_MAYFAIL flag (and not just the bulk allocator). Which is actually better, as allocating the data page for the ring buffer tracing should try hard but not trigger the OOM killer. Link: https://lore.kernel.org/all/CAHk-=wjMMSAaqTjBSfYenfuzE1bMjLj+2DLtLWJuGt07UGCH_Q@mail.gmail.com/ Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20251125121153.35c07461@gandalf.local.home Suggested-by: Linus Torvalds Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 7c727dfce6be ("ring-buffer: Prevent resizing of persistent ring buffer") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2ca6b43edf83f8fc368cc3094ee5f3b1e8e0b0f0 Author: Tejun Heo Date: Wed Aug 19 07:14:20 2026 -0400 sched_ext: Take cgroup_lock() first in scx_cgroup_lock() [ Upstream commit 5f8b69642d18e1f3e11996707842ac530444e959 ] scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes cgroup_lock(), which can deadlock through kernfs: scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgroup_lock() percpu_down_write(rwsem) cgroup_lock() kernfs_get_active() percpu_down_read(rwsem) kernfs_drain() The enable path waits for the rmdir to release cgroup_mutex. The rmdir, deactivating the cpu controller's files, waits in kernfs_drain() for the write's active reference. The write, in scx_group_set_weight(), waits for the rwsem behind the pending writer. Take cgroup_lock() first. The set_* paths take no cgroup locks inside the read side, so a pending write-lock then only waits for read sections that always run to completion, and no dependency from the rwsem back to cgroup_mutex remains. Fixes: a5bd6ba30b33 ("sched_ext: Use cgroup_lock/unlock() to synchronize against cgroup operations") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ dropped the `#ifdef CONFIG_EXT_GROUP_SCHED` guards since the code already sits inside one, and applied to kernel/sched/ext.c instead of kernel/sched/ext/ext.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f786e6652b9317c0dcfcd5c2e4fa49642a2ccf9a Author: Tejun Heo Date: Wed Aug 19 07:14:19 2026 -0400 sched_ext: Reorganize enable/disable path for multi-scheduler support [ Upstream commit dbd542a8fac7bcfba91e353f2a522e1bf2fbee27 ] In preparation for multiple scheduler support, reorganize the enable and disable paths to make scheduler instances explicit. Extract scx_root_disable() from scx_disable_workfn(). Rename scx_enable_workfn() to scx_root_enable_workfn(). Change scx_disable() to take @sch parameter and only queue disable_work if scx_claim_exit() succeeds for consistency. Move exit_kind validation into scx_claim_exit(). The sysrq handler now prints a message when no scheduler is loaded. These changes don't materially affect user-visible behavior. v2: Keep scx_enable() name as-is and only rename the workfn to scx_root_enable_workfn(). Change scx_enable() return type to s32. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Stable-dep-of: 5f8b69642d18 ("sched_ext: Take cgroup_lock() first in scx_cgroup_lock()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0907f81536f7db049f36adf3e7551125be4b7c11 Author: Tejun Heo Date: Wed Aug 19 07:14:18 2026 -0400 sched_ext: Update p->scx.disallow warning in scx_init_task() [ Upstream commit 0454a604b98a9bf301e82860cd216ec4ac563668 ] - Always trigger the warning if p->scx.disallow is set for fork inits. There is no reason to set it during forks. - Flip the positions of if/else arms to ease adding error conditions. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Stable-dep-of: 5f8b69642d18 ("sched_ext: Take cgroup_lock() first in scx_cgroup_lock()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a7e941ca29a608c6244cbd028d3599ecaef7207 Author: Yao Kai Date: Sat Aug 15 11:55:12 2026 -0400 futex: Fix race in futex_pivot_pending() during private hash resize [ Upstream commit 8e7ff730dd96519a333d1570edf1c3fabb6d3629 ] A task performing a custom private hash resize can remain blocked in uninterruptible sleep indefinitely. The hung-task detector reports: INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311 Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: hung_task: blocked tasks futex_pivot_pending() allows the resize request to continue when either no replacement hash is pending (hash_new == NULL) or the current hash reference count has reached zero. After the final-reference wake, another futex task can complete the pivot between the two observations: T1 T2 futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new != NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new = NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph = rcu_dereference(hash) /* new */ futex_ref_is_dead(fph) -> false schedule() The pivot changes the state from hash_new != NULL with a dead current hash to hash_new == NULL with a live current hash. Because futex_pivot_pending() reads hash_new and hash without serialization, the resize task can observe hash_new in the pre-pivot state and hash in the post-pivot state, causing futex_pivot_pending() to return false even though the pivot has completed. The task then goes to sleep after the wakeup has already been consumed. Serialize state reads in futex_pivot_pending() using futex_mm_phash::lock. This guarantees that futex_pivot_pending() observes hash_new and hash atomically, eliminating the race condition. Fixes: bd54df5ea7ca ("futex: Allow to resize the private local hash") Suggested-by: Peter Zijlstra Signed-off-by: Yao Kai Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260804125530.3933754-1-yaokai34@huawei.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 870f8392b284e0f538167816593f0bc98989f354 Author: Tu Nguyen Date: Wed Aug 12 06:46:59 2026 -0400 can: rcar_canfd: change the initializing flow for clocks and resets [ Upstream commit bef9004c5b91debfceaea2841855a4ebe81ff2b3 ] Testing CANFD on RZ/G3E shows that many registers do not reset to their initial values with the current flow of deasserting resets first and then enabling clocks. Based on the HW manual, clocks should be supplied first and the resets deasserted afterward. section 7.4.3 Procedure for Activating Modules: RZ/G2L section 4.4.9.3 Procedure for Starting up Units: RZ/G3E So, update the order of the initializing flow for resets and clocks to match the hardware manual, resetting all CANFD registers to their initial values. Also update rcar_canfd_global_deinit() to assert resets before disabling clocks, so the teardown path mirrors the new init ordering. Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family") Signed-off-by: Tu Nguyen Signed-off-by: Biju Das Tested-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20260625135216.130450-1-biju.das.jz@bp.renesas.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 45bf067681ad580f4d8f3a42259a3b312ea46c12 Author: Geert Uytterhoeven Date: Wed Aug 12 06:46:58 2026 -0400 can: rcar_canfd: Extract rcar_canfd_global_{,de}init() [ Upstream commit fa5f4ec8fff8bc587a2cbf7101303306e045c11f ] Extract the code to (de)initialize global state into separate functions, for future reuse. Signed-off-by: Geert Uytterhoeven Signed-off-by: Biju Das Link: https://patch.msgid.link/20251124102837.106973-5-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde Stable-dep-of: bef9004c5b91 ("can: rcar_canfd: change the initializing flow for clocks and resets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7a4ca927857aea4d68524b240aa8854d5aec1dd Author: Biju Das Date: Wed Aug 12 06:46:57 2026 -0400 can: rcar_canfd: Use devm_clk_get_optional() for RAM clk [ Upstream commit eda3d6c8d784835cec86f42b3f8118c9eb0cc58c ] Replace devm_clk_get_optional_enabled()->devm_clk_get_optional() as the RAM clk needs to be enabled in resume for proper operation in STR mode for RZ/G3E SoC. Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251124102837.106973-4-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde Stable-dep-of: bef9004c5b91 ("can: rcar_canfd: change the initializing flow for clocks and resets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f8c8c81707d17a93a0de46beda5a41d4311e7dc0 Author: Geert Uytterhoeven Date: Wed Aug 12 06:46:56 2026 -0400 can: rcar_canfd: Invert global vs. channel teardown [ Upstream commit 790ec4c453890f1221ea595674a1206bbee41dc4 ] Global state is initialized and torn down before per-channel state. Invert the order to restore symmetry. Signed-off-by: Geert Uytterhoeven Reviewed-by: Vincent Mailhol Reviewed-by: Biju Das Signed-off-by: Biju Das Link: https://patch.msgid.link/20251124102837.106973-3-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde Stable-dep-of: bef9004c5b91 ("can: rcar_canfd: change the initializing flow for clocks and resets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 562d4befa9357006018a9591a7016be230b7c0ec Author: Geert Uytterhoeven Date: Wed Aug 12 06:46:55 2026 -0400 can: rcar_canfd: Invert reset assert order [ Upstream commit 41c13eaf39932fc79aa1ac245a9b97090fe23d5e ] The two resets are asserted during cleanup in the same order as they were deasserted during probe. Invert the order to restore symmetry. Signed-off-by: Geert Uytterhoeven Reviewed-by: Vincent Mailhol Reviewed-by: Biju Das Signed-off-by: Biju Das Link: https://patch.msgid.link/20251124102837.106973-2-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde Stable-dep-of: bef9004c5b91 ("can: rcar_canfd: change the initializing flow for clocks and resets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 867aed6a4848761190d5ebdedf9642648f97bceb Author: Christian Brauner Date: Tue Aug 11 09:14:28 2026 -0400 binfmt_misc: don't leak the user namespace when the mount fails [ Upstream commit b8206f516fe7cbe785cf44bf09c17c438d7c3cad ] bm_get_tree() takes a reference to the user namespace and hands it to get_tree_keyed() as the sget key. sget_fc() moves that reference into sb->s_fs_info and clears fc->s_fs_info, so from that point on the superblock owns it and bm_free() doesn't see it anymore. The superblock drops it in ->put_super(). But generic_shutdown_super() only calls ->put_super() from inside the if (sb->s_root) branch, so nothing releases it when bm_fill_super() fails: - The kzalloc_obj() failure leaves s_root NULL and the whole branch is skipped. - A simple_fill_super() failure in the file loop leaves s_root set, but s_op still points at simple_super_operations, which has no ->put_super(). bm_fill_super() installs s_ops only once simple_fill_super() returned success, and installing it earlier wouldn't help either because simple_fill_super() overwrites s_op. Either way vfs_get_super() calls deactivate_locked_super() and the reference is gone for good. binfmt_misc mounts are available in a user namespace and both the inode and the dentry cache are SLAB_ACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simple_fill_super() on demand and leak one user namespace per attempt. Drop the reference in ->kill_sb() instead, which runs unconditionally, the same way nfsd and rpc_pipefs release their keyed s_fs_info. That also stops ->put_super() from clearing s_fs_info while the superblock is still on @fs_supers. generic_shutdown_super() leaves it there on purpose so that sget_fc() keeps finding it until kill_sb() has run, but a NULL s_fs_info makes test_keyed_super() miss it, so a concurrent mount for the same user namespace skips the grab_super() wait and creates a second superblock for a namespace that is still being torn down. Link: https://patch.msgid.link/20260728-work-binfmt_misc-usernsleak-v1-1-dbd8d5e626e7@kernel.org Fixes: 21ca59b365c0 ("binfmt_misc: enable sandboxed mounts") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c8d7595a10a630bc7ab8b017ca88944f92b39b0 Author: Damien Le Moal Date: Mon Aug 10 21:10:16 2026 -0400 ata: libata-scsi: terminate deferred commands on time out [ Upstream commit 2e1d2e65e773d67dab163127f11a47dab0fbca9f ] If a command times out while we have deferred non-NCQ commands waiting to be issued, the SCSI EH task is not immediately woken up as the waiting deferred commands are never issued nor completed, thus leaving the SCSI host in a busy state (shost->host_failed != scsi_host_busy(shost)) which prevents the SCSI EH task from being woken up. Eventually, when the deferred commands also time out, the SCSI EH task is woken up and the timeout processing occurs. Avoid this unnecessary SCSI EH task wake-up additional time by scheduling a retry of all waiting deferred QCs, using the eh_timed_out SCSI host template operation. The function ata_scsi_eh_timed_out() is introduced to implement this operation. However, terminating deferred commands with DID_REQUEUE to force a retry by calling the function ata_scsi_requeue_deferred_qc() may still keep the SCSI host in a busy state because the block layer may immediately re-issue these commands. The solution to this is to schedule libata EH for the port which suffered the command timeout to prevent accepting any new command. ata_scsi_requeue_deferred_qc() is modified to add a call to ata_port_schedule_eh() for this purpose. In addition to this change, ata_scsi_requeue_deferred_qc() is also modified to take a new timedout_scmd scsi command argument which indicates the SCSI command that timed out. With this additional argument, ata_scsi_requeue_deferred_qc() can now also terminate with DID_TIME_OUT any timed out deferred qc, which simplifies ata_scsi_cmd_error_handler(). In this case, ata_scsi_requeue_deferred_qc() returns SCSI_EH_DONE, with this return value propagated back to the ata_scsi_eh_timed_out() operation to indicate to scsi_timeout() that the timed out command was handled and no further processing is needed. For non-timed out deferred qc that need to be retried, ata_scsi_requeue_deferred_qc() returns SCSI_EH_NOT_HANDLED, thus indicating to scsi_timeout() that the timed out command needs to go through the SCSI EH (and libata EH) processing by adding it to the EH work queue with scsi_eh_scmd_add(). One side effect of these changes is that the function atapi_qc_complete() needs to be modified to ensure that a deferred ATAPI command that needs to be retried is completed with DID_REQUEUE instead of the default SAM_STAT_GOOD status, and a command that timed out is completed with DID_TIME_OUT instead of SAM_STAT_CHECK_CONDITION. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Igor Pylypiv Tested-by: Igor Pylypiv Reviewed-by: Niklas Cassel Reviewed-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db488d653d896fcf9ac87e15239924c2928bbc3c Author: Mark Brown Date: Mon Aug 10 20:22:37 2026 -0400 ASoC: tas2562: Validate values for volume writes [ Upstream commit 8fb41964f7e4e4207c8999af2056894caa7a252a ] tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array. Cc: stable@vger.kernel.org Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-1-97bf467c924e@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f0a99ea721203a4063618aafcca32abf573cb96 Author: Weiming Shi Date: Mon Aug 10 09:39:47 2026 -0400 KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs [ Upstream commit 9910e835580fef3bef53b70241dd00c4bffad693 ] Cancel (and flush) the I/O APIC's delayed EOI handling work during the "pre VM destroy" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s). Canceling the work after vCPUs are destroyed leads to UAF if the delayed work is processed after vCPUs are destroyed. BUG: KASAN: slab-use-after-free in __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 Read of size 8 at addr ffff8880499abea0 by task kworker/1:2/1218 CPU: 1 UID: 0 PID: 1218 Comm: kworker/1:2 Not tainted 7.1.0-rc7 #5 PREEMPT(lazy) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events kvm_ioapic_eoi_inject_work Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345 kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h:129 ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492 kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c:532 process_one_work+0xa59/0x19a0 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x72b/0xd30 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Note, the VM is unreachable once kvm_destroy_vm() starts, and scheduling new work via kvm_ioapic_send_eoi() can only be done via KVM_RUN, i.e. requires a live vCPU. Alternatively, KVM could simply destroy the I/O APIC during the "pre" phase of VM destruction, but that gets more than a bit sketchy as KVM expects the I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization in particular has a bad habit of touching VM-scope state during vCPU destruction. E.g. attempting to free the PIC during the pre phase would lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not hard to imagine the I/O APIC having a similar flaw. Fixes: 17bcd7144263 ("KVM: x86: Free vCPUs before freeing VM state") Reported-by: Reported-by: Zhong Wang Reported-by: Xuanqing Shi Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi Co-developed-by: Sean Christopherson Signed-off-by: Sean Christopherson Message-ID: <20260727171718.543491-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ef60eca789ee635858064af5ae232f625a9f27c8 Author: Usama Arif Date: Mon Aug 10 06:57:55 2026 -0400 userfaultfd: wait on source PMD during UFFDIO_MOVE [ Upstream commit 4165b7d1c45c2da0dfefe528f8d1fb7d79f0d344 ] move_pages_huge_pmd() snapshots src_pmdval under src_ptl, drops the lock, and, for migration entries, waits with pmd_migration_entry_wait(). Passing &src_pmdval is wrong. pmd_migration_entry_wait() must lock and re-read the real page-table PMD; on split-PMD-lock kernels, a stack address also resolves to the wrong lock. softleaf_entry_wait_on_locked() then waits without a folio reference, which is safe only while serialized against migration-entry removal by the real PT lock. Pass src_pmd, matching __handle_mm_fault() and hmm_vma_walk_pmd(). Link: https://lore.kernel.org/20260705131231.1499198-1-usama.arif@linux.dev Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Reported-by: sashiko-bot Link: https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=8 Signed-off-by: Usama Arif Reviewed-by: Rik van Riel Reviewed-by: Baolin Wang Reviewed-by: Lance Yang Acked-by: David Hildenbrand (Arm) Reviewed-by: Lance Yang Reviewed-by: Lorenzo Stoakes Cc: Andrea Arcangeli Cc: Barry Song Cc: Dev Jain Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Shakeel Butt Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea563ed2b10ae35a3122a7dafd82f070e4bed2c4 Author: Lorenzo Stoakes Date: Mon Aug 10 06:57:54 2026 -0400 mm: replace pmd_to_swp_entry() with softleaf_from_pmd() [ Upstream commit 0ac881efe16468503e8c1e7d8a7210b75f027ce3 ] Introduce softleaf_from_pmd() to do the equivalent operation for PMDs that softleaf_from_pte() fulfils, and cascade changes through code base accordingly, introducing helpers as necessary. We are then able to eliminate pmd_to_swp_entry(), is_pmd_migration_entry(), is_pmd_device_private_entry() and is_pmd_non_present_folio_entry(). This further establishes the use of leaf operations throughout the code base and further establishes the foundations for eliminating is_swap_pmd(). No functional change intended. [lorenzo.stoakes@oracle.com: check writable, not readable/writable, per Vlastimil] Link: https://lkml.kernel.org/r/cd97b6ec-00f9-45a4-9ae0-8f009c212a94@lucifer.local Link: https://lkml.kernel.org/r/3fb431699639ded8fdc63d2210aa77a38c8891f1.1762812360.git.lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Reviewed-by: SeongJae Park \ Reviewed-by: Vlastimil Babka Cc: Alexander Gordeev Cc: Alistair Popple Cc: Al Viro Cc: Arnd Bergmann Cc: Axel Rasmussen Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christian Borntraeger Cc: Christian Brauner Cc: Claudio Imbrenda Cc: David Hildenbrand Cc: Dev Jain Cc: Gerald Schaefer Cc: Gregory Price Cc: Heiko Carstens Cc: "Huang, Ying" Cc: Hugh Dickins Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Joshua Hahn Cc: Kairui Song Cc: Kemeng Shi Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Mathew Brost Cc: Matthew Wilcox (Oracle) Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oscar Salvador Cc: Pasha Tatashin Cc: Peter Xu Cc: Rakie Kim Cc: Rik van Riel Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Wei Xu Cc: xu xin Cc: Yuanchu Xie Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: 4165b7d1c45c ("userfaultfd: wait on source PMD during UFFDIO_MOVE") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 54a09573eb440989761d6b99a8e02ad227d67fa4 Author: Lorenzo Stoakes Date: Mon Aug 10 06:57:53 2026 -0400 fs/proc/task_mmu: refactor pagemap_pmd_range() [ Upstream commit de4d6c94914f3659f0b51725e23e637d4e9f78cc ] Separate out THP logic so we can drop an indentation level and reduce the amount of noise in this function. We add pagemap_pmd_range_thp() for this purpose. While we're here, convert the VM_BUG_ON() to a VM_WARN_ON_ONCE() at the same time. No functional change intended. Link: https://lkml.kernel.org/r/f9ce7f3bb57e3627288225e23f2498cc5315f5ab.1762812360.git.lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka Cc: Alexander Gordeev Cc: Alistair Popple Cc: Al Viro Cc: Arnd Bergmann Cc: Axel Rasmussen Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christian Borntraeger Cc: Christian Brauner Cc: Claudio Imbrenda Cc: David Hildenbrand Cc: Dev Jain Cc: Gerald Schaefer Cc: Gregory Price Cc: Heiko Carstens Cc: "Huang, Ying" Cc: Hugh Dickins Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Joshua Hahn Cc: Kairui Song Cc: Kemeng Shi Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Mathew Brost Cc: Matthew Wilcox (Oracle) Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oscar Salvador Cc: Pasha Tatashin Cc: Peter Xu Cc: Rakie Kim Cc: Rik van Riel Cc: Ryan Roberts Cc: SeongJae Park Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Wei Xu Cc: xu xin Cc: Yuanchu Xie Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: 4165b7d1c45c ("userfaultfd: wait on source PMD during UFFDIO_MOVE") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 549148d5aa4e3eb8d6fe061b48825a6148681745 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Aug 9 10:02:38 2026 -0400 btrfs: zoned: fix missing chunk metadata reservation [ Upstream commit 8bc4d7209611e8aa9d5409b6a4a86a9eb91b69a3 ] reserve_chunk_space() stores the return value of btrfs_zoned_activate_one_bg() in ret. The helper can return 1 after successfully activating a block group, but ret is later used to decide whether to reserve metadata for chunk tree updates. As a result, successful activation skips btrfs_block_rsv_add() and leaves trans->chunk_bytes_reserved unchanged. Use a separate variable for the activation result so positive success does not affect the later reservation. Keep activation failures in ret instead of returning early so the function uses the common tail path. Fixes: b6a98021e401 ("btrfs: zoned: activate necessary block group") CC: stable@vger.kernel.org Reviewed-by: Johannes Thumshirn Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 58ae8b7e8dc88733ff5f5b7b07916c581188a1e2 Author: Filipe Manana Date: Sun Aug 9 10:02:37 2026 -0400 btrfs: remove fs_info argument from btrfs_zoned_activate_one_bg() [ Upstream commit a232ff90d14657c8637c6e94b606bb5d700a2ecb ] We don't need it since we can grab fs_info from the given space_info. So remove the fs_info argument. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 8bc4d7209611 ("btrfs: zoned: fix missing chunk metadata reservation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d9e9753dfd43bd27c956578df7804a3c90b80fdc Author: Namjae Jeon Date: Sat Aug 8 10:09:48 2026 -0400 ksmbd: validate minimum PDU size for transform requests [ Upstream commit cfc0b8e5080aec87700774e8568765eaa4b7b92b ] The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation. Fixes: 368ba06881c3 ("ksmbd: check the validation of pdu_size in ksmbd_conn_handler_loop") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-31063 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 15a2fedb5dff384e4df98bd4a53a0d4154d8bf13 Author: ChenXiaoSong Date: Sat Aug 8 10:09:47 2026 -0400 smb/server: fix minimum SMB2 PDU size [ Upstream commit 4c7d8eb9a79ae5400eac19c4f6f0815bff674452 ] The minimum SMB2 PDU size should be updated to the size of `struct smb2_pdu` (that is, the size of `struct smb2_hdr` + 2). Suggested-by: David Howells Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Reviewed-by: David Howells Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23d34ce118857854fc0fe6754d8e78385ba71770 Author: ChenXiaoSong Date: Sat Aug 8 10:09:46 2026 -0400 smb/server: fix minimum SMB1 PDU size [ Upstream commit 3b9c30eb8f5aaad4a54cdfa470b74c0467cc71e8 ] Since the RFC1002 header has been removed from `struct smb_hdr`, the minimum SMB1 PDU size should be updated as well. Fixes: 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") Suggested-by: David Howells Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Reviewed-by: David Howells Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5649004f71613a3c46dd27744b51c220c7d8da96 Author: Namjae Jeon Date: Sat Aug 8 10:09:45 2026 -0400 ksmbd: rename smb2_get_msg to smb_get_msg [ Upstream commit 0b444cfd8b74ebce421ccd96eac9c495e536c92e ] With the removal of the RFC1002 length field from the SMB header, smb2_get_msg is now used to get the smb1 request from the request buffer. Since this function is no longer exclusive to smb2 and now supports smb1 as well, This patch rename it to smb_get_msg to better reflect its usage. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 29dbb4e29e1f197172b1a0513f65c3ff6ec4fbc8 Author: David Howells Date: Sat Aug 8 10:09:44 2026 -0400 ksmbd: Fix to handle removal of rfc1002 header from smb_hdr [ Upstream commit 0a70cac7896712a08e3cd22c16f44be976d40dbf ] The commit that removed the RFC1002 header from struct smb_hdr didn't also fix the places in ksmbd that use it in order to provide graceful rejection of SMB1 protocol requests. Fixes: 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") Reported-by: Namjae Jeon Link: https://lore.kernel.org/r/CAKYAXd9Ju4MFkkH5Jxfi1mO0AWEr=R35M3vQ_Xa7Yw34JoNZ0A@mail.gmail.com/ Cc: ChenXiaoSong Signed-off-by: David Howells Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df3cf61adbe68eb5c78e9b867963b568f819e34c Author: ChenXiaoSong Date: Sat Aug 8 10:09:43 2026 -0400 smb/server: rename include guard in smb_common.h [ Upstream commit 01ab0d1640e379f0a0d6602250b33ff2b45e9560 ] Make the include guard more descriptive to avoid conflicts with include guards that may be used in the future. Signed-off-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d154c3c0f5d9dae0f204696704c6c1f54ce61ba Author: ZhangGuoDong Date: Sat Aug 8 10:09:42 2026 -0400 smb: move get_rfc1002_len() to common/smbglob.h [ Upstream commit 36c31540cf5279262bfd148d8537cd04866499f2 ] Rename get_rfc1002_length() to get_rfc1002_len(), then move duplicate definitions to common header file. Co-developed-by: ChenXiaoSong Signed-off-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ddc2eb0d2da9c83f54f1e5720525b461b8480c4 Author: Aldo Ariel Panzardo Date: Sat Aug 8 08:05:49 2026 -0400 net/sched: serialize qdisc_rtab_list against concurrent get/put [ Upstream commit f43ee0c0730d6191629b5ee1ceae27b1ebfdc047 ] qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock. Fixes: 470502de5bdb ("net: sched: unlock rules update API") Suggested-by: Eric Dumazet Signed-off-by: Aldo Ariel Panzardo Cc: stable@vger.kernel.org Acked-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260715114114.446841-1-qwe.aldo@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 89df5d71f83f8e2781286798fd8ae5e42cf5f1a7 Author: Pavitra Jha Date: Fri Aug 7 22:52:22 2026 -0400 libceph: fix two unsafe bare decodes in decode_lockers() [ Upstream commit a109a556115271ca7896dcda7b4b7e45e156c227 ] decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ] Cc: stable@vger.kernel.org Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 590b07ceea138d49c9b64f65d263aa902d3b4730 Author: Xiang Mei Date: Fri Aug 7 18:09:57 2026 -0400 libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE [ Upstream commit 9f00f9cf2be293efe899db67dc5272e3a9c62717 ] __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ] Cc: stable@vger.kernel.org Fixes: a303bb0e5834 ("libceph: introduce and switch to decode_pg_mapping()") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 89a50fb32d69a42e857173c945f80b1cf2d1a988 Author: Andy Shevchenko Date: Fri Aug 7 18:09:56 2026 -0400 libceph: Amend checking to fix `make W=1` build breakage [ Upstream commit 04d8712b079327409b09dee628378f9583e2e035 ] In a few cases the code compares 32-bit value to a SIZE_MAX derived constant which is much higher than that value on 64-bit platforms, Clang, in particular, is not happy about this net/ceph/osdmap.c:1441:10: error: result of comparison of constant 4611686018427387891 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1441 | if (len > (SIZE_MAX - sizeof(*pg)) / sizeof(u32)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/ceph/osdmap.c:1624:10: error: result of comparison of constant 2305843009213693945 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1624 | if (len > (SIZE_MAX - sizeof(*pg)) / (2 * sizeof(u32))) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by casting to size_t. Note, that possible replacement of SIZE_MAX by U32_MAX may lead to the behaviour changes on the corner cases. Signed-off-by: Andy Shevchenko Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Stable-dep-of: 9f00f9cf2be2 ("libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a3bc6b3e9ef3f5f5cb85a902a30a090c7931127c Author: Max Kellermann Date: Fri Aug 7 14:50:03 2026 -0400 ceph: fix hanging __ceph_get_caps() with stale mds_wanted [ Upstream commit 50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6 ] A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ] Cc: stable@vger.kernel.org Fixes: 0a454bdd501a ("ceph: reorganize __send_cap for less spinlock abuse") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 79d95b43ca090426399651ed580dd9bf2db36ab8 Author: Max Kellermann Date: Fri Aug 7 11:50:05 2026 -0400 ceph: avoid fs reclaim while using current->journal_info [ Upstream commit 5b602344a49e039e792ce5a8923bcc61412ee134 ] handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data. Cc: stable@vger.kernel.org Fixes: 315f24088048 ("ceph: fix security xattr deadlock") Signed-off-by: Max Kellermann Reviewed-by: Viacheslav Dubeyko Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb13785d549992165f861e45b601b07d5b37c905 Author: Christoph Hellwig Date: Wed Jul 29 15:00:58 2026 +0200 xfs: check v5 superblock features early commit eb6b2cc1fc8ad566d746d128a559989ff0bba5cc upstream. When working on a new features that reuses the existing pad in the superblock, I noticed that mounting such a file system on an old kernel logs a rather confusing warning: XFS (vdc): Metadir superblock padding fields must be zero. This is because we only validate the various feature fields in v5 superblocks after the common superblock validation helper is called. Fix this by calling the feature validation first. Fixes: eca383fcd63b ("xfs: refactor superblock verifiers") Cc: # v4.19 Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 04228b8ba196f03d3c546374d126c995011dd2c0 Author: Darrick J. Wong Date: Sun Jul 26 22:25:50 2026 -0700 xfs: check xfarray iteration errors when committing unlinked inode lists commit 2daf3ed5d059dec79c123aec42eb8d28e0c016d4 upstream. LOLLM noticed that we neglect to check for xfarray_iter itself returning errors when writing a new AGI. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") 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 33b56c6c465aab3bfbf708450552c4553d9da32c Author: Darrick J. Wong Date: Sun Jul 26 22:26:52 2026 -0700 xfs: don't ignore runtime errors in xrep_iunlink_reload_next commit 0052633527158b49762ab427e73924e4f8d25e6c upstream. LOLLM complained that this function ignores runtime errors being returned by xrep_iunlink_store_*. Rework the function signature so that we can return runtime errors to abort the repair. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") 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 38a4dbe588bd028a07a77dc5cee62ee3ce21e87d Author: Long Li Date: Mon Jul 27 10:38:49 2026 +0800 xfs: don't swallow dquot recovery verification errors commit e2b4a856085e9bd939bde2dee0d08b1d41babde9 upstream. xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk. Fixes: 9c235dfc3d3f ("xfs: dquot recovery does not validate the recovered dquot") Cc: stable@vger.kernel.org # v6.8 Signed-off-by: Long Li Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 0f27b22343b63e10773e6781344640c2c753eec3 Author: Lin Jiapeng Date: Tue Jul 28 15:19:10 2026 +0800 xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN commit b2d5a81dae385333f9734910277fbf94c78bd17f upstream. When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents. Reported-by: Lin Jiapeng (TencentOS Red Team) Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Cc: stable@vger.kernel.org # v6.10 Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Lin Jiapeng Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit cd1f876d1bc2e94f271e07c606cacd85b109108a Author: Darrick J. Wong Date: Sun Jul 26 22:24:17 2026 -0700 xfs: avoid UAF on sc->tempip in xrep_tempfile_create commit 0c88e10d12de9ca7cbed1467bb1b52310101bff8 upstream. LOLLM noticed a potential UAF if the tempfile creation code fails after it set sc->tempip. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: 84c14ee39dd388 ("xfs: create temporary files and directories for online repair") 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 e75150d494dcd4f05edb3e2fd5becd954775e21c Author: Darrick J. Wong Date: Sun Jul 26 22:23:31 2026 -0700 xfs: don't return EFSCORRUPTED when scrubbing corrupt parent pointers commit 8af9cd79cdf6ee96ec610d707db22244fa21eb40 upstream. LOLLM noticed that scrub sets the CORRUPT flag when xfs_parent_from_attr thinks it's been given a corrupt parent pointer. This eliminates the potential to repair the filesystem because that error code is bubbled up the call stack. Fix this by collapsing them all to ECANCELED in xchk_parent_pptr, which doesn't have that trait. Cc: stable@vger.kernel.org # v6.10 Fixes: 0d29a20fbdba89 ("xfs: scrub parent pointers") 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 b6baf0db357fb84f3f3cfd33383a00de71a5a1c3 Author: Darrick J. Wong Date: Sun Jul 26 22:26:21 2026 -0700 xfs: fix another iunlink infinite loop bug in online fsck commit 6d67c6b99f1fc07c64b97fcbc974c6f1ada7f622 upstream. xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the incore prev and next unlinked list pointers based on what it finds on disk and in memory before we move on to relinking the truly lost inodes back into the unlinked list. However, it's still vulnerable to infinite loops that come in via the next_unlinked pointers. Fix this problem by remembering which inodes we've already seen and checking new agino pointers against that. If a bit is already set, either this is a loop or the inode has nonzero link count. We'll deal with the second case in a subsequent patch. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit fc7d8a5c5fcc7175e8ba7ffec4d3bf7ce6a206fd Author: Darrick J. Wong Date: Sun Jul 26 22:26:06 2026 -0700 xfs: fix allocated inodes that show up in the unlinked list commit 68ab37650ce5195b4f4f8466444a36a78207840c upstream. If an allocated inode shows up in the unlinked list, we need to get it completely off the list. Set the corrected next/prev pointers such that the inode will not look like it should be on an unlinked list at all. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c36d7f68f1c2e7e528ad11044a0bd6a3016a6a03 Author: Darrick J. Wong Date: Sun Jul 26 22:25:04 2026 -0700 xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair commit 1e96a00e0d3a00be6e4f368b2f18e2d345f813ce upstream. LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket tries to walk ragi->sc->sa.agi_bp to rebuild the unlinked inode lists. Unfortunately, it's possible for agi_bp to be null if the buffer verifier fails, so we have to use ragi->agi_bp (which skips verifier checks) instead. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") 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 73ffd2620df3ab07b9665d6619a8a8237c743034 Author: Darrick J. Wong Date: Sun Jul 26 22:23:46 2026 -0700 xfs: don't zap the attr fork on repair when there are queued pptr updates commit 5ee37132ea81abd36213b31a72140660c2aac54b upstream. LOLLM noticed that xrep_xattr_rebuild_tree doesn't check for queued parent pointer updates when it decides that it's going to zap the attr fork. This is obviously incorrect, so fix that. We hold the IOLOCK and the ILOCK of sc->ip at that point in time, so we can't race with any /new/ operations. Cc: stable@vger.kernel.org # v6.10 Fixes: e5d7ce0364d8ee ("xfs: replay unlocked parent pointer updates that accrue during xattr repair") 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 514a5d42d4188fc5f1499a8d654c717ebf981193 Author: Long Li Date: Mon Jul 27 10:38:48 2026 +0800 xfs: fix ilock leak on error in xfs_dq_get_next_id commit 63320a0f70f66f311f4bccff3af0719c2119f46c upstream. xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly. Fixes: bda250dbaf39f ("xfs: rewrite xfs_dq_get_next_id using xfs_iext_lookup_extent") Cc: stable@vger.kernel.org # v4.12 Signed-off-by: Long Li Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9680b1929d897f74e92fe6b17b06bb4c505fa6d5 Author: Darrick J. Wong Date: Sun Jul 26 22:25:19 2026 -0700 xfs: load next_agino from the correct xfarray in xrep_iunlink_relink_prev commit 6b9cd540138a06660a843a519facc147060acbef upstream. LOLLM notices that xrep_iunlink_relink_prev has the comment "set the forward pointer..." but then loads the value from the xfarray that stores pointers to the previous inode in the unlinked list. That's wrong, so fix the variable access. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") 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 8b52fa8fb3abbfae6317bdcadb298a5c5adfeda9 Author: Darrick J. Wong Date: Sun Jul 26 22:24:02 2026 -0700 xfs: nlink scrub must take IOLOCK before determining ILOCK state commit b1a296fc2241f724ef8f14da6a4efa800d444dac upstream. In xchk_nlinks_ilock_dir, take the IOLOCK before accessing internal inode state to figure out if we need to take ILOCK shared or exclusive. That way we can't race with directory updates. LOLLM pointed out that the code was initially correct w.r.t. the IOLOCK, but then I broke it. Cc: stable@vger.kernel.org # v6.18 Fixes: f477af0cfa0487 ("xfs: fix locking in xchk_nlinks_collect_dir") 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 7d1d82c463e2249375319f508bec1d498fef4689 Author: Darrick J. Wong Date: Sun Jul 26 22:25:35 2026 -0700 xfs: pass runtime errors from xrep_iunlink_mark_ondisk_rec up to callers commit 5644fab990fc72406dddc91cbb8304659d77f3f1 upstream. LOLLM points out that the only error that xrep_iunlink_mark_ondisk_rec returns is ENOMEM, but we ignore that, and can end up writing a garbage AGI based on incomplete information. We shouldn't do that, though here we must be screen out EFSCORRUPTED/EFSBASDCRC because we haven't checked the inobt yet. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") 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 ab4e1333707632baa2b22cf24d73c804bb1d2a78 Author: Darrick J. Wong Date: Sun Jul 26 22:26:37 2026 -0700 xfs: set the prev pointer when reinserting an inode on the unlinked list commit af146cb7ff8ff5c54162f35c238f3ff1d5ad110f upstream. If we find a rogue free inode and decide to reinsert it into the unlinked list, we need to set the prev pointer to NULLAGINO so that the incore list gets updated. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ce2a7006ec5ed88db1b1669124ec85bc1714ccaa Author: Darrick J. Wong Date: Sun Jul 26 22:23:15 2026 -0700 xfs: don't double-lock when deleting a self-referential directory commit 5fc643fb86599e29b38e7b2c2680b4b15bf8f772 upstream. LOLLM notices that the dirtree scrubber can detect a directory that refers to itself. In this case, it's not correct for the directory tree repair code to try to iolock/ilock both sc->ip and dp, because they're the same inode. Fix this by detecting that corner case and handling it appropriately. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") 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 983588e756a309976b7a15931d4610eb79061c31 Author: Darrick J. Wong Date: Sun Jul 26 22:22:59 2026 -0700 xfs: only check mergeability of bnobt records commit 97efed1091a50e4dbf31307015138b43a972d2e4 upstream. In the cntbt (free space by block count) btree, records are not supposed to be in startblock order. Hence the mergeability check is pointless. Remove it, since it does nothing, as LOLLM points out. Cc: stable@vger.kernel.org # v6.4 Fixes: d5784ae82778d9 ("xfs: flag free space btree records that could be merged") 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 62c0b1435dfe2a4ad50fc0e6dd523e78fbbaa88b Author: Darrick J. Wong Date: Mon Jul 20 20:24:33 2026 -0700 xfs: zero i_nlink before repair puts inode on unlinked list commit 49933254ba8d421ed706cbe6ed0fbc264e572cab upstream. LOLLM observes that we don't reset i_nlink if we encounter a file with no parent that isn't on the unlinked list. This causes unnecessary assertion trips on debugging kernels and an inconsistent file, so let's fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: 669dfe883c8e20 ("xfs: update the unlinked list when repairing link counts") 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 a9114c6d4ec2f85892c679e24894c1dd1be3e223 Author: Darrick J. Wong Date: Mon Jul 20 20:24:02 2026 -0700 xfs: fix transaction block reservation in xrep_rtbitmap commit 61606f8846a9da8ab7d2d36ff4617134c9d6df1b upstream. LOLLM pointed out an inconsistency in the block reservation code in xrep_rtbitmap. The first is that the reservation computation is not consistent between the code that sets up the repair and the code that tries to avoid exceeding the transaction reservation once we know how big the rtbitmap really must be. As a result, the logic doesn't work. In fixing that, a second problem emerges: if we do readjust, we ask for the entire reservation all over again. We really only need the delta, so ask only for that. Fix all these problems by hoisting the computation to a trivial helper so that it gets used in both places. Cc: stable@vger.kernel.org # v6.14 Fixes: 8defee8dff2b20 ("xfs: online repair of realtime bitmaps for a realtime group") 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 90a49b8fcf8219e40a6ed032def3b725f35f8933 Author: Darrick J. Wong Date: Mon Jul 20 20:23:46 2026 -0700 xfs: check cowextsize in xrep_inode_cowextsize commit 270ffcd9b0a46254fbf3079d0e3341db7d7ec0e6 upstream. LOLLM points out that the function that corrects cowextsize should check i_cowextsize, not i_extsize. Cc: stable@vger.kernel.org # v6.14 Fixes: a9600db96f74af ("xfs: detect and repair misaligned rtinherit directory cowextsize hints") 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 069c0eadc8df0ae65208c2f1a6dee73c238ed7c7 Author: Qiang Ma Date: Thu Jul 16 17:22:45 2026 +0800 xfs: clear zapped attr fork state when bmap repair finds no attr fork commit 87b2a82e135ba81e49d82b59e3d72468cb66ea98 upstream. xfstests xfs/377 can make xfs_scrub repeatedly check and repair the attr block map after inode repair zaps an attr fork. When inode repair zaps an attr fork, it records XFS_SICK_INO_BMBTA_ZAPPED so that scrub/repair can revisit the attr fork block map. If the fork has been reset to an empty state and removed, BMBTA repair has no attr fork mappings to rebuild and can return success. The post-repair scrub then runs with XREP_ALREADY_FIXED set, which means xchk_file_looks_zapped() deliberately ignores the stale zapped health bit and asks xchk_bmap() to check the current attr fork. For an absent attr fork, xchk_bmap() returns -ENOENT. Returning that error prevents xchk_bmap_attr() from marking XFS_SICK_INO_BMBTA_ZAPPED healthy, leaving the zapped health state behind even though there are no attr fork mappings left to check. Treat -ENOENT during post-repair BMBTA revalidation as a clean result for the zapped attr fork: clear XFS_SICK_INO_BMBTA_ZAPPED and return success. Keep the existing -ENOENT behavior for ordinary scrubs of absent attr forks. Fixes: d9041681dd2f ("xfs: set inode sick state flags when we zap either ondisk fork") Cc: stable@vger.kernel.org # v6.8 Reviewed-by: "Darrick J. Wong" Signed-off-by: Qiang Ma Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit aeadf3fd2dc3c83649aee335ff82a88e334770c7 Author: Darrick J. Wong Date: Mon Jul 20 20:24:48 2026 -0700 xfs: mark nonzero sb_gquotino as corrupt on metadir filesystems commit b28d23c51635b646784a2a62c71ba99458c07d5e upstream. On a metadir filesystem, the superblock gquotino field is always zero because we find the quota inodes through the metadata directory tree. A nonzero value is therefore a corruption (as pointed out by LOLLM) so mark the failure as such. Cc: stable@vger.kernel.org # v6.13 Fixes: 06b20ef09ba163 ("xfs: check pre-metadir fields correctly") 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 f8288214459ead7e87d26e5822f62c14a4f2ed6b Author: Ibrahim Hashimov Date: Wed Jul 15 09:17:23 2026 +0200 xfs: bounds-check buffer log item's dirty bitmap commit 813f8136a2ce1fee266d02a7df73db6e8a541604 upstream. xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), item->ri_buf[i].iov_base, nbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Reviewed-by: "Darrick J. Wong" Reviewed-by: Brian Foster Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8a0ecae2ecda9f9a83a496ed05c42c4b1f5c3f2d Author: Xiang Mei Date: Tue Jul 14 14:56:12 2026 -0700 xfs: fix off-by-one in rtrefcount btree root level validation commit cc3144da377de5fb422d44a2311f978623f7c900 upstream. xfs_rtrefcountbt_compute_maxlevels() sets mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1; where the trailing "+ 1" already accounts for the inode-root level, so the deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels). The two on-disk validation paths, xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount(), check the root level with ">" instead of ">=", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1, exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is sized for exactly bc_maxlevels entries, the first btree op on such a cursor indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an FS_IOC_GETFSMAP over the realtime device. Reject a root level equal to m_rtrefc_maxlevels, matching the ">=" form already used by the sibling data-device refcount/rmap verifiers and the in-memory rtrmap verifier. BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308) xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113) xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085) xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551) xfs_mountfs (fs/xfs/xfs_mount.c:1158) xfs_fs_fill_super (fs/xfs/xfs_super.c:1940) get_tree_bdev_flags (fs/super.c:1634) vfs_get_tree (fs/super.c:1694) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216 The buggy address is located 8 bytes to the right of allocated 216-byte region [ffff888018391578, ffff888018391650) Kernel panic - not syncing: Fatal exception Cc: stable@vger.kernel.org # v6.14 Fixes: 9abe03a0e4f978 ("xfs: introduce realtime refcount btree ondisk definitions") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ec19cea4ef1ce9d6e2e3f7e9e7bf88ede31176e7 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Jul 12 03:42:56 2026 +0000 xfs: propagate errors from xfs_rtginode_load commit b7e53968cb8882c2d276429ea8550848a4940874 upstream. xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than -ENOENT as success. This can leave the realtime group inode unset after an I/O, allocation, or corruption error. Growfs then continues as though the inode had been loaded. Only -ENOENT means that the inode needs to be created. Return all other errors to the growfs caller. Fixes: ae897e0bed0f ("xfs: support creating per-RTG files in growfs") Cc: stable@vger.kernel.org Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: Christoph Hellwig Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 71aa45f7bfe46fbc6f51e7832573ff49b6005fea Author: Junrui Luo Date: Thu Aug 6 12:45:24 2026 +0800 drm/amdgpu: disallow multiple FENCE chunks in one submit commit 931cd1d1baeae68e8eb2c23bc1f3d8934dca6241 upstream. amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did for p->bo_list. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Reviewed-by: Christian König Signed-off-by: Junrui Luo Signed-off-by: Alex Deucher (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82) Signed-off-by: Greg Kroah-Hartman commit 25ee120f3803ad9e416ef9f76f4c3234cc4d645b Author: David Rosca Date: Thu Jul 30 18:01:51 2026 +0200 drm/amdgpu: Fix UVD decode image min size calculation commit b8bb9ba3f101a1b0011f785a577a4a0a38371174 upstream. This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 38914cb2c6afb5fe00241ea3438e655822196378 Author: David Rosca Date: Thu Jul 30 17:56:17 2026 +0200 drm/amdgpu: Fix UVD dpb min size calculation for H264 commit 21a8084cd76223a13493237e04d45f5226d7cee6 upstream. This should use actual number of references from the decode message, instead of maximum derived from level. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c76e5cca0675b83d3a7bf69282c3cf5754c336c6 Author: David Rosca Date: Thu Jul 30 18:05:52 2026 +0200 drm/amdgpu: Fix UVD min buffer sizes commit 18727670b44753865b81c56a9338c0d7bd102c54 upstream. Use correct size for message buffer = sizeof(struct ruvd_msg). Add ITSCALING_TABLE_BUFFER size. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 37519d007e4261febbcf35b3045f8344f3145497) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 86a5cb020322156b188b16ddec94872dbdbfc5ba Author: David Rosca Date: Mon Aug 10 11:11:35 2026 +0200 drm/amdgpu: Implement insert_end for VCE 3 commit d5ab4c6a64efef2d143a96df5357f59703cd703d upstream. After a recent change VCE now hangs when VCE_CMD_END is emitted after a pipeline sync without VM flush. Implement insert_end to correctly insert only one VCE_CMD_END per job. Fixes: bc639a9eadc7 ("drm/amdgpu: always emit the job vm fence") Signed-off-by: David Rosca Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 8897ea8c761b856f02061848a7908040a1fe5e68) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 339deb76ee4859ea973e435c9a9a4a4fefc29338 Author: David Rosca Date: Thu Jul 30 17:37:44 2026 +0200 drm/amdgpu: Reject UVD message with dimensions above 4096 commit 8c9aebcdd9f46f7a14b98d6ab18574b7a48fbb08 upstream. Fixes potential overflow in DPB size calculations. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 05e1387d151f71569fbe122d2c89f9db0c21dc10) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 220aa2589d7321fb68d2e8597862711b5f22ae0b Author: Candice Li Date: Mon Jul 27 11:51:37 2026 +0800 drm/amdgpu: validate GEM_CREATE domain combinations commit 5e9d136ad74df4edec67e502ce267597064d8f86 upstream. AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) Signed-off-by: Candice Li Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a082bd76c5f255ff825276f168b1143bc2fc2816 Author: Yang Wang Date: Wed Aug 5 20:39:18 2026 +0800 drm/amdgpu: check ASPM on the dGPU host link commit 2a9c5154a5650c09ad44ff5e1dff74754e15a3c6 upstream. dGPUs with an internal PCIe switch expose graphics functions below the switch downstream port. The automatic ASPM check uses the display endpoint and evaluates the internal link instead of the host link. Use the switch upstream port for the check and report the selected link. Fixes: 0ab5d711ec74 ("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device") Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 4e0d6f2876e704fff707b18c40dbd383aea4a1c9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 916e8a1550be1a96f5af2f12bd3e78ffbcd96e9b Author: Yang Wang Date: Mon Aug 10 12:48:19 2026 +0800 drm/amdgpu: fix nbif 6.3.1 l1 low power not functional commit cd688a3cb342b9f56399aa076157f1c324c15c5a upstream. The PCIe L1 low‑power settings for NBIF 6.3.1 were never applied due to unresolved register mapping, which caused the relevant code to be compiled out. As a result, the PCIe link could not enter L1/L23 power‑down states or transition to L0s. Properly configure the link control register to enable L1 and L23 power‑down, and permit L0s link transitions. Keep LTR disabled and let the PCI core enable it only after verifying end‑to‑end root complex support across switches. Fixes: 894c6d3522d1 ("drm/amdgpu: Add nbif v6_3_1 ip block support") Signed-off-by: Yang Wang Signed-off-by: Kenneth Feng Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c2417f9fd7049d5a8d87eefd82fd6e36ba1ff7b6) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e304c3e0d9ce251887be1f274aa0ed52219d5fd7 Author: David Rosca Date: Tue Aug 11 11:03:10 2026 +0200 drm/amdgpu: Reject UVD message with invalid number of h265 refs commit 9fca434208f1f9ab977feac62df8ebb1cc7ce893 upstream. Same change as for h264, avoids overflow later when calculating min dpb size. Signed-off-by: David Rosca Reviewed-by: Leo Liu Signed-off-by: Alex Deucher (cherry picked from commit a4b0720e4f1601f97f59a2be9c1b4b94fa6527d5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e3e6a631dcb1c32bd12c602fe51364ed5f5c3d27 Author: Nathan Lucas Date: Sun Aug 2 08:35:24 2026 -0600 drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE commit cd22349e86faf6e15e6c622d70c0efc57d43201e upstream. The commit cited by the Fixes tag added separate limited and full-range BT.2020 YCbCr entries to the DCE output CSC tables, but populated both entries with the same matrix copied from the common DC table. That matrix combined full-range scaling with limited-range luma offset and was incorrect for both limited and full-range output. Replace the coefficients in both entries in the DCE paths with those from the new COLOR_SPACE_YCBCR2020_LIMITED_TYPE and COLOR_SPACE_YCBCR2020_FULL_TYPE entries in the preceding commit ("drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix"). Fixes: 51e6668ab4ba ("drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs") Assisted-by: OpenAI-Codex:GPT-5.6-Sol Tested-by: Igor Paunovic Tested-by: Satyajit Roy Signed-off-by: Nathan Lucas Signed-off-by: Alex Deucher (cherry picked from commit 14c8726b79d19934d6eb6d35c612e3f7204af2c6) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cd99fa1cbaf5a5d745b90aacc39442d10fce71d1 Author: Nathan Lucas Date: Sun Aug 2 08:35:23 2026 -0600 drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix commit 2f9a5c0f018d4a1586ee892f81f1383219676415 upstream. COLOR_SPACE_YCBCR2020_TYPE, which is selected for COLOR_SPACE_2020_YCBCR_LIMITED color_space, has coefficients that are incorrect for limited-range output. Its luma and chroma scaling is full-range so output is too bright and colors are incorrect. COLOR_SPACE_YCBCR2020_TYPE is closer to a full-range conversion matrix with incorrect luma offset, so correct the luma offset for full-range and rename it to COLOR_SPACE_YCBCR2020_FULL_TYPE. Add COLOR_SPACE_YCBCR2020_LIMITED_TYPE with correct scaling and range for limited-range output. Fix related functions so COLOR_SPACE_YCBCR2020_LIMITED_TYPE and COLOR_SPACE_YCBCR2020_FULL_TYPE are correctly selected based on dc_color_space. Derivation of both matrices follows ITU-T H.273: Table 4, MatrixCoefficients 9, BT.2020-NCL weights: KR = 0.2627, KB = 0.0593, KG = 1 - KR - KB = 0.6780. Equations 45-47 in matrix form: [ KR KG KB 0 ] M2020_NCL = [ -KR/(2(1-KB)) -KG/(2(1-KB)) 1/2 0 ] [ 1/2 -KG/(2(1-KR)) -KB/(2(1-KR)) 0 ] [ 0 0 0 1 ] Limited and Full transforms based on equations 30-32 and 36-38 with bit depth 10, normalized by 1023: [ 876/1023 0 0 64/1023 ] MLimited = [ 0 896/1023 0 512/1023 ] [ 0 0 896/1023 512/1023 ] [ 0 0 0 1 ] [ 1023/1023 0 0 0 ] MFull = [ 0 1023/1023 0 512/1023 ] [ 0 0 1023/1023 512/1023 ] [ 0 0 0 1 ] M2020_NCL_Limited = MLimited x M2020_NCL M2020_NCL_Full = MFull x M2020_NCL The upper three rows of M2020_NCL_* are stored in CR, Y, CB order. Each M2020_NCL_* value is stored as Round(value * 8192) in its 16-bit two's-complement representation. Fixes: 973a9c810c78 ("drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix") Assisted-by: OpenAI-Codex:GPT-5.6-Sol Tested-by: Igor Paunovic Tested-by: Satyajit Roy Signed-off-by: Nathan Lucas Signed-off-by: Alex Deucher (cherry picked from commit 3b906e1dc7e3c9ff9f7940f6828b367a6a9ec73c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5045fb4c70bfde36a05e0f41cf35ddfb6d85d3af Author: Samuel Pitoiset Date: Fri Aug 7 16:58:55 2026 +0200 drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank() commit f2a1c4c6fe0a6fcde02e59dde546dba28d283635 upstream. amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before a stream is attached to it. BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu] Call Trace: drm_vblank_enable drm_vblank_get drm_crtc_get_sequence_ioctl drm_ioctl_kernel drm_ioctl Reproduced by running VKCTS with WSI tests enabled on RADV. Guard the enable path on acrtc_state->stream being non-NULL, matching the existing checks in this function. Fixes: 34d66bc7ff10 ("drm/amd/display: Fix Xorg desktop unresponsive on Replay panel") Reviewed-by: Melissa Wen Signed-off-by: Samuel Pitoiset Signed-off-by: Alex Deucher (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 95c1de6923b063431f020c1d1edf8af8061aeec2 Author: Harald Freudenberger Date: Mon Aug 3 10:33:34 2026 +0200 s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code commit 5004889551dfaf7f4b2cda8ed213d234bb8ebf82 upstream. Both CPRB alloc functions in zcrypt_ccamisc.c and zcrypt_ep11misc.c did not round up the memory allocation to a multiple of 4 bytes as it is needed by the zcrypt layer to process the CPRBs. Now the alloc_and_prep_cprbmem() and alloc_cprbmem() functions guarantee that the base CPRB struct and a possible parameter block are aligned to a 4-byte boundary and the backing memory allocation is rounded up to the next multiple of 4 byte. Also the free_cprbmem() is updated and scrubs the rounded up amount of memory. Fixes: 9bdb5f7e8369 ("s390/zcrypt: Introduce cprb mempool for cca misc functions") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 7902be374cbfc11c3435e1e87bf22195bf06a558 Author: Eric Farman Date: Tue Jul 28 05:30:22 2026 +0200 s390/vfio_ccw: Implement a crw lock commit 16b0798024c0e9117e395829ddbbe70981c79d9c upstream. Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively. Fixes: 3f02cb2fd9d2 ("vfio-ccw: Wire up the CRW irq and CRW region") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Reviewed-by: Farhan Ali Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 3b224d3c50a382c48460e1ba513d72b66368848e Author: Eric Farman Date: Tue Jul 28 05:30:17 2026 +0200 s390/vfio_ccw: Calculate idal length based on idaw type commit 4f6fdc6e1a7fbfa36b945af33c65a417948feac0 upstream. Sashiko pointed out that get_guest_idal() unconditionally calculates the length of the IDAL presuming everything is a Format-2 IDAW. The output of vfio-ccw is always Format-2, but the input can be either Format-1 (31-bit addresses) or Format-2 (64-bit addresses). As a result, the size of the guest IDAL may be incorrect and should be trimmed down. Reported-by: sashiko-bot Link: https://lore.kernel.org/r/20260720203400.7328E1F000E9@smtp.kernel.org/ Fixes: 1b676fe3d9d3 ("vfio/ccw: handle a guest Format-1 IDAL") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit b6aecea4b2b246f9fbd98a5712daa1193a60818e Author: Eric Farman Date: Tue Jul 28 05:30:21 2026 +0200 s390/vfio_ccw: Selectively expand io_mutex commit 34f4feff3e90bd09308fad0974e97113b23b812a upstream. The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself. Fixes: 4f76617378ee ("vfio-ccw: protect the I/O region") Cc: stable@vger.kernel.org Signed-off-by: Eric Farman Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit af1759d8e6e6da9ba94f30a2f92546f406899aa7 Author: Eric Farman Date: Tue Jul 28 05:30:20 2026 +0200 s390/vfio_ccw: Move cp cleanup out of not operational commit 0c11f61a876ed6fcca53d442ed3f33ea8362a0f9 upstream. The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements. Fixes: 204b394a23ad ("vfio/ccw: Move FSM open/close to MDEV open/close") Cc: stable@vger.kernel.org Signed-off-by: Eric Farman Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 4c2e1d359d7a2b82cdf3254e4e480af9417f99fb Author: Eric Farman Date: Tue Jul 28 05:30:15 2026 +0200 s390/vfio_ccw: Fix out of bounds check on CCW array commit a005b7f1a491ffda61bff0fd0f6548f8986fb977 upstream. The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is "do..while (count < 257)", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range. Fixes: 0a19e61e6d4c ("vfio: ccw: introduce channel program interfaces") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 08ef2a82115690d6e229615872ac1731af732497 Author: Eric Farman Date: Tue Jul 28 05:30:16 2026 +0200 s390/vfio_ccw: Ensure first IDAW remains constant commit 565bef268d75bf7df665bce6923a88cd0eb74592 upstream. The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with. Fixes: 01aa26c672c0 ("s390/cio: Combine direct and indirect CCW paths") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 649badf3a2fd8929e40198603a2cb21b74c21700 Author: Eric Farman Date: Tue Jul 28 05:30:18 2026 +0200 s390/vfio_ccw: Ensure index for read/write regions are within range commit 9f5f9a78fedc45bc29d6a0a64e3a3472361afae5 upstream. The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced. Fixes: db8e5d17ac03 ("vfio-ccw: add capabilities chain") Cc: stable@vger.kernel.org Cc: Cornelia Huck Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit b7ae0f7993867d009a4b554fc1d6d451c10580a0 Author: Eric Farman Date: Tue Jul 28 05:30:19 2026 +0200 s390/vfio_ccw: Cancel existing workqueues commit 79c60b2c61105368dcc8444eb45847e21734f7c4 upstream. The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd. Suggested-by: Matthew Rosato Fixes: e5f84dbaea59 ("vfio: ccw: return I/O results asynchronously") Fixes: 3f02cb2fd9d2 ("vfio-ccw: Wire up the CRW irq and CRW region") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 06f4d6e5a8af6c2072e8cd39dbc512c683ca7fb2 Author: Eric Farman Date: Tue Jul 28 05:30:14 2026 +0200 s390/vfio_ccw: Limit the number of channel program segments commit 5405c90d6a47b3014e74ee0618a162449abbbc93 upstream. The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive. Fixes: 0a19e61e6d4c ("vfio: ccw: introduce channel program interfaces") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 32e3d364a7b8295120d37e6a6bd433d2de26f748 Author: Eric Farman Date: Tue Jul 28 05:30:13 2026 +0200 s390/vfio_ccw: Free all memory if cp_init() fails commit 74186c2968f8f756ac3226b545b598457c910c75 upstream. The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic. Fixes: 8b515be512a2 ("vfio-ccw: Fix memory leak and don't call cp_free in cp_init") Cc: stable@vger.kernel.org Reviewed-by: Farhan Ali Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 45aa38567c798b764cf42d3e6a23efce8e3d614c Author: Jakub Kicinski Date: Wed Jan 28 11:32:58 2026 -0800 eth: bnxt: make sure we populate the qcfg defaults on old FW/HW commit 3cf48c04966e1945de6c89bc9c0746ace2e7ddec upstream. The driver now depends on the core to tell it what the rx page size should be for the agg ring. We must populate the ndo_default_qcfg callback even if we don't support any queue ops. This fixes: Oops: divide error: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN RIP: 0010:bnxt_alloc_rx_page_pool (drivers/net/ethernet/broadcom/bnxt/bnxt.c:3852) with fw version 225.1.109.0. Link: https://lore.kernel.org/20250421222827.283737-20-kuba@kernel.org Fixes: f96e1b35779e ("eth: bnxt: support qcfg provided rx page size") Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260128193258.125274-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Cc: Max Kellermann Signed-off-by: Greg Kroah-Hartman commit 0382ed41c66455972fcf322dbf3f8cefb8c09323 Author: Jakub Kicinski Date: Wed Jan 21 16:51:08 2026 -0800 eth: bnxt: always set the queue mgmt ops commit 1410c7416dc343f15e9b7152eabddbdbe483002d upstream. Core provides a centralized callback for validating per-queue settings but the callback is part of the queue management ops. Having the ops conditionally set complicates the parts of the driver which could otherwise lean on the core to feed it the correct settings. Always set the queue ops, but provide no restart-related callbacks if queue ops are not supported by the device. This should maintain current behavior, the check in netdev_rx_queue_restart() looks both at op struct and individual ops. Reviewed-by: Subbaraya Sundeep Link: https://patch.msgid.link/20260122005113.2476634-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Cc: Max Kellermann Signed-off-by: Greg Kroah-Hartman commit 31ef57083e785cbea4d5fde05a44d9050c9c42c4 Author: Guangshuo Li Date: Sat Aug 8 21:59:42 2026 +0800 drm/radeon: fix autosuspend cleanup during teardown commit 587be7a17358ef8c0106775fcedae5a7bef50735 upstream. radeon_driver_load_kms() calls pm_runtime_use_autosuspend() for PX devices, but radeon_driver_unload_kms() 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. 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 driver unload path. This issue was found by manual code inspection. Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)") Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 0fdc1ff82ea14844c22795e9e0813c3ca03235e1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 361114857813d53a80ff0cd983280e3ff9988109 Author: Raag Jadav Date: Mon Aug 10 18:08:20 2026 +0530 drm/xe: Fix xe_device_probe() failure commit ef526d122b62af5afa437f095aa6661a953676c4 upstream. Currently, xe_device_probe() jumps to err_unregister_display label in case of failure except for its last call, which directly returns the error without required cleanup handling. This results in stale drm device that isn't cleaned up on unwind. Fix it. [ 810.194180] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 810.194183] CPU: 9 UID: 0 PID: 5616 Comm: modprobe Kdump: loaded Tainted: G S U E 7.2.0-rc2-xe #382 PREEMPT(full) [ 810.194185] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER, [E]=UNSIGNED_MODULE [ 810.194186] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1805 10/30/2024 [ 810.194186] Call Trace: [ 810.194187] [ 810.194188] dump_stack_lvl+0xe0/0x100 [ 810.194195] dump_stack+0x14/0x20 [ 810.194197] sysfs_warn_dup+0x5f/0x80 [ 810.194204] sysfs_create_dir_ns+0xbe/0xd0 [ 810.194210] kobject_add_internal+0xbc/0x2b0 [ 810.194215] kobject_add+0x7c/0xe0 [ 810.194220] ? get_device_parent+0xcf/0x1e0 [ 810.194227] device_add+0xe3/0x870 [ 810.194231] ? __pfx_drm_gem_name_info+0x10/0x10 [drm] [ 810.194280] drm_minor_register+0x73/0x130 [drm] [ 810.194322] drm_dev_register+0x76/0x2a0 [drm] Cc: stable@vger.kernel.org Fixes: da3799c97572 ("drm/xe: Use GuC to do GGTT invalidations for the GuC firmware") Signed-off-by: Raag Jadav Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260810123821.105605-1-raag.jadav@intel.com Signed-off-by: Matt Roper (cherry picked from commit 5ce3042c67c539480882567137ff8d56118885d6) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 7b90db6f024b838ec296a7815e38bb2522a54844 Author: Matthew Brost Date: Fri Aug 7 10:17:16 2026 -0700 drm/xe: Order ring writes before ring tail updates commit 9f83c94469ff0fa37274b873ba24922e02531fa7 upstream. The ring buffer and the LRC context image are both mapped WC, so the ring tail update can become visible to the device before the ring contents it is meant to publish. The GuC CT send does contain an xe_device_wmb(), so sending the H2G would flush the ring contents. The problem is that it comes too late: xe_lrc_set_ring_tail() publishes the tail before the H2G is sent, and the device samples the tail from the context image independently of it, either at context switch-in or while the context is already resident. A submitter which is interrupted between updating the tail and sending its H2G therefore leaves the device free to observe the new tail while the ring contents behind it are not yet visible: 1. Thread A emits a job into the ring, sets the tail to T_A and sends the H2G, which flushes A's ring contents. The GuC starts scheduling the context in, but it is not executing yet. 2. Thread B emits a job into ring[T_A..T_B]. Those writes are not yet visible to the device. 3. Thread B updates the ring tail to T_B. That write targets a different page and becomes visible first. 4. Thread B is interrupted before it sends its H2G, so the flush which would have published ring[T_A..T_B] has not happened yet. 5. The context is switched in and samples the ring tail from the context image, picking up T_B rather than T_A. 6. The GPU executes A's job, advances HEAD to T_A, and continues on to ring[T_A..T_B], which still holds the previous wrap's contents, so the CS parses stale commands. The result is command stream corruption, which typically manifests as a hang or a spurious pagefault rather than anything that points back at the submission path. Kernel jobs are by far the most likely to hit this. Kernel queues such as the migration queue are shared and can be driven by many threads concurrently, producing back-to-back submissions on an LRC which is already executing. User queues are typically tied to a single submitting thread, so the same interleaving is much harder to produce. Add an xe_device_wmb() at the end of xe_lrc_write_ring() so that it covers every ring tail publication site, and so the invariant is local: once xe_lrc_write_ring() returns, the ring contents are visible to the device. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8651 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7810 Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Assisted-by: GitHub_Copilot:claude-opus-5 Reviewed-by: Stuart Summers Link: https://patch.msgid.link/20260807171716.140475-1-matthew.brost@intel.com (cherry picked from commit 136360290f314890428a3fbf31aaa8e4f1d43567) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 198b4a89b9033ed7336862ce6bc91ce7ad37d506 Author: Dmitry Osipenko Date: Wed Jul 29 15:59:07 2026 +0300 pmdomain: mediatek: Fix mt8183 hang on boot commit 818d56ac1d08b68a4c42d0326786f030cc640722 upstream. Depending on firmware, part of the MFG domains may be partially left ON at boot time with kernel detecting PD as ON, while it's OFF. Some of MFG cores may be left powered after bootloader, to let the ACP to prefetch the GPU region when the display controller is brought up for a continuous splash animation performed by downstream stack. This doesn't play well with an eventual delay in probing upstream Panfrost driver when the display controller is fully set up, as that would make genpd's sync_state() to power off the domain while ACP tries to prefetch: this is causing an AXI stall, effectively freezing the AP indefinitely. In order to prevent trouble from happening, the sync_state() functionality must be obliterated on all of the MFG domains: while this guarantees a power leakage if the bootloader boots the kernel with MFG PDs partially powered on, this is the only way to ensure stable operation of the SoC during boot on devices with such firmware because, of course, those will never officially receive a firmware update. Fixes Kappa Chromebook hanging during system boot. Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state") Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Dmitry Osipenko Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8f7f7a6d5aed8f346a1c936fba02033c73a337dc Author: Binbin Zhou Date: Tue Aug 4 14:12:00 2026 +0800 mmc: loongson2: Fix sg iteration in data reorder functions commit 00179ed9fbe07799676e2cb63c4e7f0e7cd80a5c upstream. In ls2k0500_mmc_reorder_cmd_data() and ls2k2000_mmc_reorder_cmd_data(), the for_each_sg() macro already iterates over the scatterlist entries, with 'sg' pointing to the current entry. However, the code incorrectly uses '&sg[i]' and 'sg_dma_len(&sg[i])' inside the loop, which treats 'sg' as an array base and indexes it again, leading to access of wrong sg entries (or out-of-bounds if the list is not an array). Cc: stable@vger.kernel.org Fixes: d0f8e961deae ("mmc: loongson2: Add Loongson-2K2000 SD/SDIO/eMMC controller driver") Fixes: 2115772014bd ("mmc: loongson2: Add Loongson-2K SD/SDIO controller driver") Signed-off-by: Binbin Zhou Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e5b527804a1ea4f70e139179d3062cf5de8c06ab Author: John Harrison Date: Thu Jul 23 15:06:52 2026 -0700 drm/connector/hdmi: Fix out of bounds memory read commit 9ecf8ba763d0ffe0673538eb4bf7806f20455d19 upstream. A helper function was copying a given audio infoframe into the connector's copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation. Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination. I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can't corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug. Fixes: f378b77227bc ("drm/connector: hdmi: Add Infoframes generation") Cc: Ville Syrjälä Cc: Dmitry Baryshkov Cc: Maxime Ripard Cc: Maarten Lankhorst Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: Dmitry Baryshkov Cc: Daniel Stone Cc: Nicolas Frattaroli Cc: Jani Nikula Cc: José Expósito Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: John Harrison Link: https://patch.msgid.link/20260723220652.533345-1-John.Harrison@Igalia.com Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit b5060ff2f5460795a3e9f7cdf5052aa42f96ff81 Author: Pei Xiao Date: Mon Aug 3 17:48:21 2026 +0800 mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition commit c125ee35a49a0518521b52b27631eef061b8719a upstream. In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove. Fixes: 7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers") Assisted-by: Codex:deepseek-v4-flash Signed-off-by: Pei Xiao Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 78e59ab343372ff986eb28530a4e19f23ab90b60 Author: AngeloGioacchino Del Regno Date: Thu Jul 16 13:42:47 2026 +0200 pmdomains: mediatek: Avoid setting RTFF's CLK_DIS before NRESTORE commit cbb0140379de69fa46526672f3003f128f0b4e2e upstream. For the PCIE_PHY (also called PEXTP_PHY) type of RTFF hardware, there is special handling setting CLK_DIS before performing the NRESTORE sequence for resetting the RTFF and start sequencing from a clean state. That special handling, though, poses an issue in case the machine specific bootchain (bootloader in particular) ends up booting the kernel with both PCIe MAC and PHY enabled (not just power domains) as doing so will partially corrupt the PCIe MAC/PHY registers in an unpredictable manner, producing either an initialization fail in the PCI-Express drivers, or even a hard lockup! Resolve this by simply removing the special handling: in this case the bootchain, or remote processors, setting is getting honored by the later check for PWR_RTFF_SAVE_FLAG presence in the RTFF ctl register. Fixes: 9d02c94342b3 ("pmdomain: mediatek: Add support for RTFF Hardware in MT8196/MT6991") Signed-off-by: AngeloGioacchino Del Regno Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7c0d1767ce464167712673157b2ce72f1c57a0e4 Author: Haibo Chen Date: Mon Jul 27 18:38:49 2026 +0800 mmc: sdhci: make tuning_err a signed int commit ae31bcc92bb42502bb7c9029e6dc7a824cf6cd14 upstream. Coverity report INTEGER_OVERFLOW for host->tuning_err. The tuning_err field in struct sdhci_host is used to store an error code for re-tuning, but it was declared as unsigned int. Several call sites store negative error codes into it and later compare against negative values: - sdhci.c, sdhci-of-dwcmshc.c and sdhci-pci-gli.c assign it the return value of __sdhci_execute_tuning()/__sdhci_execute_tuning_9750(), both of which return a signed int (possibly a negative errno); - sdhci-of-esdhc.c assigns host->tuning_err = -EAGAIN and later does "ret = host->tuning_err; if (ret == -EAGAIN ...)"; - sdhci-of-dwcmshc.c prints it with the %d (signed) conversion. Storing a negative errno in an unsigned int and reading it back as a signed int only happens to work because of two's-complement, same-width integer conversions. It is misleading and triggers sign-conversion warnings. All users treat the value either as a signed error code or as a boolean (zero / non-zero), so changing the type to a signed int is safe and makes the intent explicit. Fixes: 7d8bb1f46e13 ("mmc: sdhci: add tuning error codes") Assisted-by: Cline:claude-sonnet [read_file, search_files, git] Signed-off-by: Haibo Chen Reviewed-by: Frank Li Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 970b9c83a07c405fdd32bcce7cc4c9e670e58875 Author: Guangshuo Li Date: Wed Jul 8 17:20:38 2026 +0800 pmdomain: mediatek: fix remaining %pOF after of_node_put() commit 3e013bc8b941bd52c8e3a99798d0ae8792cb71ca upstream. scpsys_get_bus_protection_legacy() looks up several legacy bus protection regmaps from device-tree nodes. Two error paths put the device node before checking whether the regmap lookup failed, but still pass that node to dev_err_probe() with %pOF on failure. If of_node_put() drops the last reference, the later %pOF formatting can dereference a freed device node. Keep the node reference until after the error message has been emitted in the infracfg and SMI lookup paths. Also drop the SMI node before returning when the SMI phandle is missing. Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval") Signed-off-by: Guangshuo Li Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 36d1b69c5c6984df88b6e1f5782abba35a466291 Author: Myeonghun Pak Date: Mon Jul 27 23:03:22 2026 +0900 mmc: sdhci: unmap the bounce buffer before device release commit 9e9f561269dff35e6f84ed21776ec37fd6360b03 upstream. sdhci_allocate_bounce_buffer() allocates its buffer with devm_kmalloc() but maps it with dma_map_single(). The buffer is therefore released by devres without the streaming DMA mapping being unmapped. Register a managed action after dma_map_single() succeeds so the mapping is removed before devres releases the buffer. The action is registered only for buffers allocated and mapped by the SDHCI core, leaving buffers provided by host drivers under their existing ownership. Fixes: bd9b902798ab ("mmc: sdhci: Implement an SDHCI-specific bounce buffer") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Linus Walleij Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0418b7ed2c1c6f6969bb64274c8a6e20b945647a Author: Zhan Xusheng Date: Tue Aug 4 10:25:00 2026 +0800 mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit commit f64ea900e4bda3055ef24a2c906f8d049cf1c3bd upstream. omap_hsmmc_prepare_data() converts the command busy timeout to nanoseconds with: timeout = req->cmd->busy_timeout * NSEC_PER_MSEC; busy_timeout is an unsigned int (milliseconds) and timeout is a u64, but NSEC_PER_MSEC is 1000000L. On 32-bit builds the multiplication is performed in 32-bit arithmetic and wraps for busy_timeout values above ~4294 ms, before the result is assigned to the u64. The driver does not set mmc->max_busy_timeout, so the core does not cap the busy timeout, and commands such as erase or SANITIZE (MMC_SANITIZE_TIMEOUT_MS is 240000 ms) can pass a busy_timeout far larger than 4294 ms. The wrapped, much smaller ns value is then programmed via set_data_timeout(), so the data timeout is set too short and the operation can time out prematurely. Cast busy_timeout to u64 before the multiplication so the conversion is done in 64-bit arithmetic. Fixes: 8cc9a3e73de1 ("mmc: host: omap_hsmmc: use generic_cmd6_time to program timeout value for CMD6") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b37e84280045ba7bcd2eb92f8b193c75d2c25810 Author: Kefu Chai Date: Thu Jun 11 19:32:51 2026 +0800 libceph: tolerate addrvecs with multiple entries of the same type commit 5a87925539acecfe88229bad76ab81bd75a7e3f5 upstream. ceph_decode_entity_addrvec() rejects any addrvec containing more than one entry that matches the requested msgr type (LEGACY or MSGR2), logging "another match of type N in addrvec" and returning -EINVAL. Some admin tooling (e.g. pveceph mon create from Proxmox VE) generates addrvecs with multiple same-type entries when public_network lists more than one CIDR: it picks one local IP per subnet and emits both a v2 and a v1 entry for each IP. Monmaps shaped this way cause: libceph: mon0 (1)10.10.10.15:6789 session established libceph: another match of type 1 in addrvec libceph: problem decoding monmap, -22 No Ceph code uses the extra entries: since Nautilus, the userspace messenger (AsyncMessenger) unconditionally picks the first address of the requested type and ignores any subsequent matches. Match that behavior: use the first matching entry and silently skip any subsequent ones. This is a compatibility fix for existing deployments and does not enable dual-stack or multi-subnet address selection. [ idryomov: tweak ceph_decode_entity_addrvec() comment ] Cc: stable@vger.kernel.org Fixes: a5cbd5fc22d5 ("libceph, ceph: get and handle cluster maps with addrvecs") Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7518 Signed-off-by: Kefu Chai Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 4490fad7992a7f2692c87211253085931ec36ab3 Author: Yiming Zhu Date: Fri Jul 24 18:49:20 2026 +0800 ceph: fix MDS random selection readiness predicate commit 2c11c4bfdb7bd2808b3b3ac228e1f2d9bcf25457 upstream. CEPH_MDS_IS_READY() is parsed so that the ternary expression can return true for an MDS entry with state 0 when it is not laggy. This allows the random selector to choose a down/DNE rank. Group the ternary expression under the state check so zero-state ranks are not treated as ready. Cc: stable@vger.kernel.org Fixes: b38c9eb4757d ("ceph: add possible_max_rank and make the code more readable") Link: https://tracker.ceph.com/issues/78648 Signed-off-by: Yiming Zhu Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 4f392fec075562dc93bb0c69f37423ca2af9b48f Author: Raphael Zimmer Date: Tue Jul 28 10:43:40 2026 +0200 libceph: Avoid using invalid osd indices from primary_temp commit 3660b98d1204b419f6a77e9a295f148dcf38d042 upstream. A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ] Cc: stable@vger.kernel.org Fixes: 5e8d4d36bf23 ("libceph: add support for primary_temp mappings") Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit f3854719fba9f8e727b42e06767440d74d43e041 Author: Dmitry Torokhov Date: Mon Jun 15 22:12:30 2026 -0700 Input: sur40 - fix V4L error path cleanup commit 062dc4693e2c10d77de06f61e6f3faf37c0a8383 upstream. In sur40_probe(), if video_register_device() fails, the error path jumps to err_unreg_video. This incorrectly attempts to unregister a video device that was never successfully registered, and fails to free the V4L2 control handler (v4l2_ctrl_handler_free) that was initialized immediately prior. Fix this by introducing an err_free_ctrl label to properly free the V4L2 control handler and bypass video_unregister_device() when video device registration fails. Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616051235.1549517-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5c1c5227c93f18cd329dd754b4df5e0e2daece1e Author: Dmitry Torokhov Date: Mon Jun 15 22:12:29 2026 -0700 Input: sur40 - fix input device registration ordering commit 9da976eb649c9e2f588a4499410e4d8af687925f upstream. In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered. Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616051235.1549517-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a88d688be8d7f03cbf927f2ab454ea9fa58d2979 Author: Ali Ahmet Memis Date: Fri Aug 7 23:42:30 2026 +0000 openrisc: signal: do not restore privileged SR bits on sigreturn commit 32ef1b30ad736519f7a207bcc2986f3d4129d972 upstream. restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged. Fixes: ac689eb7f9d4 ("OpenRISC: Signal handling") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit f634598e8fb7b39487fba8eb257c8adb15baa5dd Author: Josh Poimboeuf Date: Wed Aug 5 21:56:46 2026 -0700 ftrace: Fix off-by-one fentry site disable in ftrace_free_mem() commit 8b8292d6487c81bd57c2605a9b404b1cf8f1edfb upstream. When a module's init text is freed, do_init_module() calls ftrace_free_mem() with a half-open [start, end) range. However the ftrace_cmp_recs() comparator treats the upper bound as inclusive, as all its other users do, passing 'ip + size - 1'. So ftrace_free_mem() can delete a record sitting exactly at 'end', which is outside the freed range. For a kernel without CFI or IBT, the first record of a function is at the function start, which for the first function in a module is also the base of its text allocation. As the module allocator packs its regions, that address is often the 'end' passed by a neighboring module's do_init_module(), causing the first function's ftrace location to get disabled, preventing an attempt to livepatch it: livepatch: failed to find location for function 'pcspkr_probe' Convert the exclusive end to the inclusive 'end - 1' the comparator expects, and return early for an empty range to avoid the subtraction from underflowing when the init text size is zero. Cc: stable@vger.kernel.org Fixes: 42c269c88dc1 ("ftrace: Allow for function tracing to record init functions on boot up") Link: https://patch.msgid.link/1b5ccfa8095bdb1277f84af1c2c2e2205aca03ae.1785992188.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f8fe843a96344bc86156acb17829d534c8c43861 Author: Leon Hwang Date: Thu Jul 30 23:04:08 2026 +0800 ftrace: Protect direct_functions in ftrace_find_rec_direct commit 63444b7617c09aeed36282e061c3f80818f2b600 upstream. Fix accessing the __rcu pointer direct_functions with RCU protection. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260730150411.88667-2-leon.hwang@linux.dev Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Acked-by: Jiri Olsa Suggested-by: Steven Rostedt Signed-off-by: Leon Hwang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d1bba38574d095f191557d397d9633f08cd966b1 Author: Pavitra Jha Date: Tue Jun 2 01:02:19 2026 -0400 libceph: fix multiple unsafe decodes in decode_locker() commit 437b6551cfcc235eea1d735a874f9d421f555e17 upstream. decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ] Cc: stable@vger.kernel.org Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit ebdecef6fd8422d26104273f713043d38d1be63c Author: Praveen Talari Date: Wed Aug 5 01:27:39 2026 +0530 pmdomain: arm: Fix -EINVAL from scmi_pd_set_perf_state() on state 0 commit 3314c90a2eda3df7da4ab6f4388e667b2758de7f upstream. Currently, scmi_pd_set_perf_state() treats a performance state of 0 as invalid and returns -EINVAL. As a result, devices attached to SCMI performance domains can report failures when relinquishing their performance vote. The OPP framework use performance state 0 to indicate that no performance vote is required. For example, dev_pm_opp_set_rate(dev, 0) is commonly used (by firmware or linux) when a device is runtime suspended. A zero performance state does not require any SCMI performance request to be sent. Treat it as a no-op and return success instead of reporting an error. Signed-off-by: Praveen Talari Fixes: 2af23ceb8624 ("pmdomain: arm: Add the SCMI performance domain") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bc7934d0acd4fc1c7e5b7c68debdb4a991121628 Author: Junjie Cao Date: Fri Jul 31 11:27:47 2026 +0800 gpio: ml-ioh: use raw_spinlock_t for the register lock commit 600411ea1f2443fdf5b1af9b6480f616d7aff9d0 upstream. ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 ("gpio: pch: use raw_spinlock_t for the register lock"); this driver shares the same structure as gpio-pch. Fixes: 54be566317b6 ("gpio-ml-ioh: Support interrupt function") Cc: stable@vger.kernel.org Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260731032747.2987292-1-junjie.cao@intel.com Signed-off-by: Junjie Cao Signed-off-by: Greg Kroah-Hartman commit 9e678cffc11c27e627e868e41d873e759765eede Author: Jordan Rhee Date: Fri Aug 7 22:43:14 2026 +0000 gve: fix zero-length skb frag with header-split commit 6bf14575c65569dcded90ef78afb8a6d57323f04 upstream. When header split is enabled and a header-only packet is received such as a pure TCP ACK, GVE will indicate an RX SKB with a zero-length fragment. If this SKB is then hairpinned and sent back out, the GVE TX path will emit a zero-length descriptor. Hardware considers this an illegal descriptor and stops the queue, causing a TX timeout and interface reset. Fix it by not adding the zero-length skb frag. Cc: stable@vger.kernel.org Fixes: 5e37d8254e7f ("gve: Add header split data path") Suggested-by: Praveen Kaligineedi Co-developed-by: Ziwei Xiao Signed-off-by: Ziwei Xiao Signed-off-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260807224315.234152-2-hramamurthy@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bd4e5a97edf8ced581acf1adf5ec59a981d0a9aa Author: Rui Qi Date: Fri Aug 7 16:15:12 2026 +0800 selftests/ftrace: Convert ELF entry point to file offset in uprobe test commit 24aa630f6259e6a2107936c06fed72063f712b64 upstream. The add_remove_uprobe test uses readelf -h to obtain the ELF entry point (e_entry) and passes it directly as the offset to uprobe_events. However, uprobe_events expects a file offset, not a virtual address. For PIE binaries, the virtual address happens to equal the file offset because the first LOAD segment has p_vaddr == p_offset, so the test works by coincidence. But for non-PIE executables, e_entry is an absolute virtual address that can far exceed the file size. When the probe is enabled, uprobe_register() checks offset > i_size_read(inode) and rejects it with -EINVAL. Fix this by converting the virtual address to a file offset using the ELF program headers: scan readelf -lW output for the LOAD segment containing the entry point, then compute file_offset = e_entry - p_vaddr + p_offset. For PIE binaries the result is unchanged; for non-PIE binaries the offset is correctly translated. The conversion uses only POSIX shell primitives, with no dependency on gawk or perl. Link: https://lore.kernel.org/all/20260807081512.2974757-3-qirui.001@bytedance.com/ Fixes: dc4b165855f2 ("selftests/ftrace: Use readelf to find entry point in uprobe test") Cc: stable@vger.kernel.org Signed-off-by: Rui Qi Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 23e9f32c0c7d2043e39655cff5ee3ddf29a43f80 Author: Cengiz Can Date: Fri Jul 31 01:02:57 2026 +0300 gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind commit 44f3468a0aef1aabdad551898ab7cfa2a9d20e99 upstream. The "trigger" debugfs file has a hand-rolled ->write handler (trigger_write()) that dereferences the per-device gpio_la_poll_priv. The file is created with debugfs_create_file_unsafe(), and the handler never takes a debugfs reference. Nothing keeps the object alive while the handler runs. priv is allocated with devm_kzalloc(). devres frees it when the platform device is unbound. debugfs_create_file_unsafe() installs no full_proxy wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not wait for an in-flight trigger_write(). The blob_lock taken there does not help, because trigger_write() never takes it. A write that races an unbind therefore writes into freed memory: trigger_write() gpio_la_poll_remove() priv = m->private buf = memdup_user() [may sleep] mutex_lock(&priv->blob_lock) debugfs_remove_recursive() [no wait] mutex_unlock(&priv->blob_lock) (remove returns; devres frees priv) priv->trig_data = buf <-- use-after-free write priv->trig_len = count The race is reachable by root via /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind. Create "trigger" with debugfs_create_file() instead. Its full_proxy wrapper makes debugfs_remove_recursive() drain any in-flight ->write before it returns. The use-after-free is confirmed under KASAN with a minimal reproducer of the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern (available on request); it produces a slab-use-after-free write in the handler. Fixes: 7828b7bbbf20 ("gpio: add sloppy logic analyzer using polling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Cengiz Can Reviewed-by: Wolfram Sang Link: https://patch.msgid.link/20260730220258.358169-2-cengiz.can@canonical.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit e9482feeed66d4bc805458631013e9b61b1a9eaf Author: Jordan Rhee Date: Fri Aug 7 22:43:15 2026 +0000 gve: fix NULL dereference due to missing ptp adjfine commit 3992ced109c70b771efad9e51ae68e5c7a04dea3 upstream. Fix NULL dereference due to missing implementation of adjfine, which can be triggered from usermode as follows: sudo ./testptp -d /dev/ptp0 -f 0 [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 552.061946] Call Trace: [ 552.064487] [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0 [ 552.070874] ? get_clock_desc+0x6b/0xb0 [ 552.074825] pc_clock_adjtime+0x78/0xc0 [ 552.078755] __do_sys_clock_adjtime+0x85/0x110 [ 552.083293] do_syscall_64+0xea/0x610 Cc: stable@vger.kernel.org Fixes: acd16380523b ("gve: Add initial PTP device support") Signed-off-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260807224315.234152-3-hramamurthy@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a134e4b8102c077286818ee112b9f925db613d4c Author: Thorsten Blum Date: Fri Jul 24 10:15:38 2026 +0200 crypto: qce - fix error path in devm_qce_register_algs commit 9c75402286409f5e1a75e4a445555c84066f89db upstream. If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead. Fixes: e80cf84b6087 ("crypto: qce - unregister previously registered algos in error path") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Bartosz Golaszewski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ef92c0ad0268ed183cb71e157e291bff3f7e1c2c Author: Thorsten Blum Date: Sat Jul 25 11:06:10 2026 +0200 crypto: starfive - use scatterlist length before DMA mapping commit 6b36f13891ab4709b7d60023005176cdd5c368cf upstream. Using sg_dma_len() is only valid after mapping a scatterlist with dma_map_sg(). However, starfive_aes_aead_do_one_req() uses it before mapping the scatterlist. Use the original scatterlist length because the DMA length has not been populated yet when CONFIG_NEED_SG_DMA_LENGTH=y. Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 38e7d5c1ade04b99c70da0298ca296ee62bc99c0 Author: Jianing Li Date: Mon Aug 3 21:18:52 2026 -0700 Input: hynitron_cstxxx - validate touch count and finger IDs commit 27f380ef0e1d3de3cde114e02d33f9320ce3a5a6 upstream. The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device. Fixes: 66603243f528 ("Input: add driver for Hynitron cstxxx touchscreens") Signed-off-by: Jianing Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260804031339.2379-1-m13940358460@163.com Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 70f9aad3943559af6f32cb303744f35c05ce9cf1 Author: Dmitry Torokhov Date: Thu Jun 25 22:17:55 2026 -0700 Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue commit 8786d74bf50e6797b6f655eb381ef6b25451161f upstream. Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-6-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ff0849705d29277fd1f6fc6596674b9308724fb2 Author: Dmitry Torokhov Date: Thu Jun 25 22:17:54 2026 -0700 Input: synaptics-rmi4 - block s_input when F54 queue is busy commit fbfd76746adc16d64be29ff113f673b70bc3f5c2 upstream. Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming). Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Hans Verkuil Link: https://patch.msgid.link/20260626051802.4033172-5-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 6b06aab79ff166d5781ce792d91acc2e58b1770b Author: Bryam Vargas Date: Thu Jun 25 22:17:52 2026 -0700 Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer commit 49c5adc2b7d6e43c5cf033e1c86fdb9c16ababb1 upstream. rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check. Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b28593a05afdd812b590e1045b5bd862a5869225 Author: Dmitry Torokhov Date: Thu Jun 25 22:17:51 2026 -0700 Input: synaptics-rmi4 - zero report size on F54 work error commit dc76c3c8e8ad09362b8c1561f3928288c15cba2e upstream. In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 828a8d1a9107aec6353d896882df8383accf7e80 Author: George Wilson Date: Fri Aug 7 11:56:21 2026 -0500 powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak commit 5b17f3f34391372faf03e79d947e0c50ab6dd258 upstream. In papr_phy_attest_create_handle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd). Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd. Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for physical-attestation RTAS") Acked-by: Haren Myneni Acked-by: Nayna Jain Tested-by: R Nageswara Sastry Cc: stable@vger.kernel.org # 6.16 Signed-off-by: George Wilson Signed-off-by: Madhavan Srinivasan Signed-off-by: Greg Kroah-Hartman commit 2bdec532202b3f3c2eaa496f2d8f6f4c3148b107 Author: George Wilson Date: Fri Aug 7 11:59:00 2026 -0500 powerpc/pseries: lparcfg - fix kbuf[] underflow commit fb442a6673ff1046bf67754957d95880fdb394b5 upstream. In lparcfg_write(), a count of 0 results in kbuf[] being indexed at -1. Check for count == 0 in the existing check for count > sizeof(kbuf) and return -EINVAL if true. Fixes: 74422e2b1939 ("powerpc/pseries: Remove VLA from lparcfg_write()") Acked-by: Nayna Jain Tested-by: R Nageswara Sastry Cc: stable@vger.kernel.org # 4.20 Signed-off-by: George Wilson Signed-off-by: Madhavan Srinivasan Signed-off-by: Greg Kroah-Hartman commit 8dbfd8e32a13e116790780ed0be82b5a05eb9916 Author: Linmao Li Date: Mon Jul 20 14:12:59 2026 +0800 Input: byd - synchronize timer deletion before freeing private data commit c83e79c0842ed29860648bcce5022ef0ba5001c6 upstream. byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op. Fixes: 2d5f5611dd0d ("Input: byd - enable absolute mode") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260720061259.1601281-1-lilinmao@kylinos.cn Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a64a8b6b31cd669f0449138e53cc2592d454ccf1 Author: Pengpeng Hou Date: Fri Jul 24 20:46:27 2026 -0700 Input: iforce - validate input packet lengths commit 5751c781d3c97ab6ce0e2a966156ed882152c415 upstream. iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260720115018.75045-1-pengpeng@iscas.ac.cn Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e7b8a107ecad54451d7e8c9f00d4aaea9fa08974 Author: Zhefu Zhang Date: Sun Aug 2 15:36:54 2026 -0700 Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard commit 3a046db33bb9f28b43a951a7a090db771dc0f8b3 upstream. The internal keyboard of the Xiaomi Book Pro 14 does not work unless atkbd skips deactivating it at the end of atkbd_probe(). Using 'i8042.dumbkbd=1' also makes the keyboard work, but then the driver never writes to the keyboard at all, so the Caps Lock LED is lost. The atkbd_deactivate_fixup quirk fixes both without a boot parameter. DMI: XIAOMI Xiaomi Book Pro 14/TM2424, BIOS XMAPT4B0P0909 05/06/2026 Signed-off-by: Zhefu Zhang Reviewed-by: Andrew Zhou Link: https://patch.msgid.link/20260802031559.19701-1-a723356@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8d622c58205adbc8af19864e277386528b671345 Author: Linmao Li Date: Fri Jul 24 18:42:06 2026 -0700 Input: psxpad-spi - set driver data before use commit 732f38c36059e68ba3b4b89c56911d777fd3185c upstream. psxpad_spi_suspend() retrieves the controller state with spi_get_drvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe. Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI") Signed-off-by: Linmao Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260721055551.1714965-1-lilinmao@kylinos.cn Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 83c265bfc084d77e2171d4b67362150ab38c935b Author: Richard Davies Date: Sun Aug 2 17:53:10 2026 -0700 Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet commit 296736076b3fd078742651c719555a488624023a upstream. Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1]. Fixes: 05be1d079ec0 ("Input: psmouse - support for the FocalTech PS/2 protocol extensions") Signed-off-by: Richard Davies Link: https://patch.msgid.link/20260701190932.14960-1-richard@arachsys.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9b184c8337c6e12df129399007735a7fbcbbcb7b Author: Dmitry Torokhov Date: Thu Jun 25 22:17:50 2026 -0700 Input: synaptics-rmi4 - fix F55 transmitter electrode count typo commit 6058f0fea10f3caf63a435677358d1b8e9325114 upstream. During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos. This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses. Fix the typos by correctly assigning the TX electrode counts. Fixes: 6adba43fd222 ("Input: synaptics-rmi4 - add support for F55 sensor tuning") Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54") Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 652e952850d9a9ae54fa24802109e6a0343b15d5 Author: George Wilson Date: Fri Aug 7 11:58:36 2026 -0500 powerpc/pseries: pci - logic bug commit 649c10bff5cb7a514bf299094833ec8c9190aac3 upstream. The checks on num_vfs in pseries_pci_sriov_enable() are ANDed where OR was apparently intended. Change it to OR. Fixes: 9a7f6b438664 ("powerpc/pseries/pci: Associate PEs to VFs in configure SR-IOV") Acked-by: Nayna Jain Tested-by: R Nageswara Sastry Cc: stable@vger.kernel.org # 4.16 Signed-off-by: George Wilson Signed-off-by: Madhavan Srinivasan Signed-off-by: Greg Kroah-Hartman commit 52a818c586ae2c36b7324bfaefb547f5e866a8ae Author: HyeongJun An Date: Sat Jul 18 16:40:32 2026 +0900 Input: cs40l50-vibra - validate custom data from user space commit 7d5c576cb1c86047b1fcb1aa9532e17fc5e46c1d upstream. cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect straight from the ff_effect the user passed to EVIOCSFF, without requiring it to hold anything: work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len; The driver then reads two words out of that buffer: custom_data[0] as the waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the index within the bank in cs40l50_effect_index_set(). Neither read is covered by a length check, and custom_len is fully user controlled: - custom_len == 0 makes memdup_array_user() call memdup_user() with a length of zero, which returns ZERO_SIZE_PTR rather than an error, so custom_data[0] dereferences it. - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps effect->type out of the OWT case, and custom_data[1] is then read one word past the allocation. The bank value itself is also mishandled. It is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a custom_data[0] of 0x8000 or above wraps to a negative value that passes the "bank_type >= CS40L50_WVFRM_BANK_NUM" test. cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the switch statement's default case gets a chance to reject it: base_index = vib->dsp.banks[effect->type].base_index; max_index = vib->dsp.banks[effect->type].max_index; Require the two words the driver reads to be present, and hold the masked bank in a u32 so the existing upper-bound test covers the whole range. The da7280 haptic driver already range checks custom_len this way. Fixes: c38fe1bb5d21 ("Input: cs40l50 - Add support for the CS40L50 haptic driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260718074032.1864861-1-sammiee5311@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 455dbb5bdd814e0d5fa0e82e54fc7df265cfab5d Author: Kyohei Kadota Date: Thu Jul 23 19:55:57 2026 +0900 Input: xpad - add support for ZENAIM LEVERLESS commit 7d971337ebfad0b173cb46097c709db174ac3557 upstream. Add the VID/PID for the ZENAIM LEVERLESS controller to xpad_device and the VID to xpad_table. Signed-off-by: KADOTA, Kyohei Link: https://patch.msgid.link/CAFMepckDUuOHiDDVVhUYc-UqJMeCqrWSfCuxbJ2x2sGgdDD4nw@mail.gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 6635d544bd6bc9a9c0ef6881117846c5b6a41428 Author: Bard Liao Date: Thu Jul 30 10:17:24 2026 +0300 ASoC: SOF: topology: Use acpi mach from the machine driver commit ae63720dd7c3647d64f7a85e5e1870f90eb569d6 upstream. The parameters may be changed by the sof_sdw machine driver is the SOC_SDW_PCH_DMIC quirk is set. Use the mach_params from the machine driver to ensure the sof_sdw_get_tplg_files() function select the right function topologies. Fixes: 2fbeff33381c ("ASoC: Intel: add sof_sdw_get_tplg_files ops") Cc: stable@vger.kernel.org Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260730071724.22296-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bcc66461f574a61ac650461cc9fd3343d3721ca5 Author: Asad Kamal Date: Thu Jul 30 15:00:00 2026 +0800 drm/amdgpu: fix aperture iounmap skipped on device removal commit f9e5f51549000e2665e3b5e02ff876b9e09cfe95 upstream. amdgpu_pci_remove() calls drm_dev_unplug() before invoking the fini routines. After drm_dev_unplug() the drm_dev_enter() guard in amdgpu_ttm_fini() always returns false, so iounmap() for aper_base_kaddr is silently skipped. On connected_to_cpu hardware ioremap_cache() maps the aperture as WB; when iounmap() is skipped the stale WB PAT entry persists. On reload IP discovery's memremap(MEMREMAP_WC) on the same aperture range hits a WB/WC conflict, producing an ioremap error and failing re-probe. Remove the drm_dev_enter() guard and call iounmap() unconditionally. The aperture mapping is plain MMIO and does not require device-presence protection. Surprise-removal cleanup of aper_base_kaddr is already handled unconditionally by amdgpu_device_unmap_mmio(). Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit fb3f68af9f6fce9343a2bd13b4d68a1c02d283df) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dffacbe8118fc87dd8844a0d0841a1a19c478167 Author: Jesse Zhang Date: Wed Jul 29 16:57:08 2026 +0800 drm/amdgpu: fix JPEG v4.0.5 queue reset failure in DPG mode commit 4301e60e406c613aea06fdc0c36bf0675b0b8a2e upstream. Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset. Acked-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 75a308eef4503a9d2bf297bef5a9317d2209e696) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e45356f6adae4f1cadc0f906e6c4b708af1c9608 Author: Jesse Zhang Date: Wed Jul 29 16:57:08 2026 +0800 drm/amdgpu: fix JPEG v5.0.0 queue reset failure in DPG mode commit c87801f545dac9fcbb84c96f280706572be00a85 upstream. In DPG mode jpeg_v5_0_0_ring_reset() takes the DPG stop path, which only clears the JPEG_PG_MODE bit and never resets the JRBC. A hung ring is not recovered: the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset which has no DPG path. Acked-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 79b3612827d1adcd2008cd585961fa35a6ff20f2) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4550b90bd2e6c768e78cc9a575e747de8e18fa72 Author: Qiang Yu Date: Thu Jul 23 17:20:47 2026 +0800 drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12 commit 2d69604b4d0b9c0c0ac71624b5fafb36cf249729 upstream. TA_CNTL2.TRUNCATE_COORD_MODE selects whether texture coordinate truncation is D3D9/GL/Vulkan conformant. gfx11 reads it and reports it to userspace via AMDGPU_IDS_FLAGS_CONFORMANT_TRUNC_COORD, but gfx12 never read it, so the flag was always reported as 0 and userspace fell back to the non-conformant path. Read it in gfx_v12_0_constants_init() like gfx11 does. Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Signed-off-by: Qiang Yu Reviewed-by: Marek Olšák Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 4261cbc7b03f1f56e95aeaf1492b8690fa5a253e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1474f3970d1afd303e12ff14d06808eabb371576 Author: Candice Li Date: Thu Jul 30 11:28:10 2026 +0800 drm/amdgpu: reject oversized IBs with per-ring packet limits commit fd37f9dd5b5ab70a46fa7bc76623c0528d602b27 upstream. On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. Signed-off-by: Candice Li Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 25556a46ae6ecf2a9f1c1c5096828eecd4596b91 Author: Osama Abdelkader Date: Fri Jul 24 19:26:20 2026 +0200 drm/panthor: skip zero-sized firmware sections commit 2b8f13d3c7e26c46c20d9e367904cf01729c88e6 upstream. panthor_fw_load_section_entry() skips BO creation when the firmware section VA range is empty. If such a section is added to the firmware section list, section->mem is left as NULL. Later reload and unplug paths iterate over all firmware sections and dereference section->mem, which can lead to a NULL pointer dereference. Zero-sized firmware sections are valid, so accept them as no-op entries but skip adding them to the section list. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20260724172621.63046-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 7ff87a01ae3a8cd0208f7499386998223a8b5dba Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Tue Jul 21 16:19:42 2026 +0800 fbdev: core: Fix pointer desynchronization in fb_io_read() commit 81cc73be40c6f028f1ee3f438ace46afe666dbae upstream. In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations. Fixes: 6121cd9ef911 ("fbdev: Move I/O read and write code into helper functions") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 2fe7a89b2b5b73be35c1e493d0246314ba54e427 Author: Dawid Wróbel Date: Thu Jul 30 12:58:13 2026 +0200 ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses commit 56f24311fd5607588a47e44675195a9efb200f29 upstream. EAR SPKR PA Gain" and the four "WSA RX* Mux" controls are enumerated, but their get and put callbacks access the value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but wsa-macro was missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check and every read of these controls fails with -EINVAL. Fixes: 809bcbcecebf ("ASoC: codecs: lpass-wsa-macro: Add support to WSA Macro") Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Assisted-by: Claude:claude-fable-5 Cc: stable@vger.kernel.org Signed-off-by: Dawid Wróbel Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-2-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cc61f0fa2c714c29cb62e2cdf4653316deef8af3 Author: Peter Ujfalusi Date: Wed Aug 5 11:24:11 2026 +0300 ASoC: cs35l41: sort the register default table commit d74aac116cfb2058b15df53996d23232b310f7ff upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l41_reg[] lists CS35L41_BSTCVRT_PEAK_CUR (0x3808) after CS35L41_BSTCVRT_COEFF (0x3810) and CS35L41_BSTCVRT_SLOPE_LBST (0x3814), so the binary search does not find those two entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 5f2f539901b0 ("ASoC: cs35l41: Correct handling of some registers in the cache") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3298f13d1f1260e31ffec5462cd8dea3874b3f8e Author: Peter Ujfalusi Date: Wed Aug 5 11:24:12 2026 +0300 ASoC: cs35l45: sort the register default table commit f39a68ed08bb6eef0ae711b41d645ee5e9448c09 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l45_defaults[] lists the DSP1_RX*_RATE and DSP1_TX*_RATE registers (0x02b80080 - 0x02b802b8) in the middle of the table, ahead of entries with much lower addresses, so the binary search does not find 36 of its 73 entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 74b14e2850a3 ("ASoC: cs35l45: DSP Support") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d7bd683b0d90cbb88e5fe36cc835d1fcbeb6faec Author: Peter Ujfalusi Date: Wed Aug 5 11:24:13 2026 +0300 ASoC: cs4265: sort the register default table commit e4fe3e046524e5de3c04c6eef3743780cbdc231c upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e), CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search does not find those three entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: fb6f806967f6 ("ASoC: Add support for the CS4265 CODEC") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f2435a46dfa1a5693cf2664afd022db66ee58121 Author: Peter Ujfalusi Date: Thu Jul 30 14:23:43 2026 +0300 ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout commit 17661c67b206612cb3ba65d5ae726cd2015d0a53 upstream. Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state. Fixes: c40aad7c81e5 ("ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20260730112343.26687-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8cba53b862e1437257ec206d303ff942684284f1 Author: Peter Ujfalusi Date: Thu Jul 30 11:59:14 2026 +0300 ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() commit e780e4917d43683224812400fe3dc4816fceba75 upstream. If either tplg_ops->dai_config or widget_kcontrol_setup fail during widget setup we would double decrement the use_count of the widget because the sof_widget_free_unlocked() would be called twice, similarly the core_put would be invoked twice as well. Since the use_count and core_put() is handled within the widget_free function we need to return without falling through the pipe_widget_free label. The fixes tag is picked to the last change around this part of the code which is adequately old enough for backporting purposes. Link: https://github.com/thesofproject/sof/issues/10826 Fixes: 31ed8da1c8e5 ("ASoC: SOF: sof-audio: Modify logic for enabling/disabling topology cores") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260730085914.27546-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a3083647747942ea32faf14560d6397ff3068046 Author: Hidayath Khan Date: Thu Jul 30 16:22:16 2026 +0200 s390/qeth: validate user buffer length in SNMP and ARP query ioctls commit d141f087b1af656f055d7c5793a3e87817ba0bbe upstream. qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow. Fixes: 4a71df50047f ("qeth: new qeth device driver") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter Signed-off-by: Hidayath Khan Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260730142216.218309-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 75e564b2ced1cc3d9a8904c7d2d2bb448fffb8b5 Author: Wyatt Feng Date: Mon Aug 3 18:16:39 2026 +0200 mptcp: fastopen: only mark MPTFO subflows with SYN data commit e00b63056fb4f261455b3e5df5268a1f8ce47a87 upstream. Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO". Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-7-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3f8e5eb0c499950054a572ea1f9a070a451e7f3e Author: Qing Luo Date: Mon Aug 3 18:16:36 2026 +0200 mptcp: pm: fix data race in add_addr timer callback commit a7aad5b69d3bdaec20a3ed9284e184502450c0cd upstream. The timer callback reads entry->retrans_times outside pm.lock to decide whether to call mptcp_pm_subflow_established(). Since mptcp_pm_announced_del_timer() can concurrently set retrans_times = ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists. I discovered this issue while studying the code. AI tools helped me to verify the issue can potentially happen under race conditions. Use a local 'retransmit' flag set inside pm.lock to capture whether retransmission is still possible when the lock is taken. This allows to call mptcp_pm_subflow_established() accordingly, and not depending on the situation that can be different when checked outside the pm.lock. Fixes: 348d5c1dec60 ("mptcp: move to next addr when timeout") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-4-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1fade1b2ac5b1a4948e538fae7313bea57b5ac36 Author: Matthieu Baerts (NGI0) Date: Mon Aug 3 18:16:33 2026 +0200 mptcp: options: reset DSS fields in case of unexpected size commit 35772b4981f38ba8059372cde8753e8e477e98ec upstream. A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size. Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d%40kernel.org?part=1 Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-1-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a04dcc784959e4702048785d87e0d029bd2fbdcb Author: Matthieu Baerts (NGI0) Date: Mon Aug 3 18:16:34 2026 +0200 mptcp: avoid combining some incoming suboptions commit b6ee361524641f57b2e2363f7737f20e17f67827 upstream. Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN. Fixes: eda7acddf808 ("mptcp: Handle MPTCP TCP options") Cc: stable@vger.kernel.org Link: https://www.rfc-editor.org/rfc/rfc8684.html#section-3.5-5.1 [1] Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-2-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0cb3846c26c112ec2b6783886f3b01b847dd7d0d Author: Gang Yan Date: Mon Aug 3 18:16:37 2026 +0200 selftests: mptcp: join: mark tests with data corruption as failed commit ca318e7bbb7723f57bcd9e69a2873b5884435552 upstream. check_transfer() compares the input and output files byte-by-byte using `cmp -l "$in" "$out" | while read ...`. Because the while-loop body runs in a subshell (the script sets neither lastpipe nor pipefail), the fail_test call inside it -- which sets the global ret/last_test_failed -- and the `return 1` both act on the subshell, not on check_transfer(). check_transfer() thus always falls through to `return 0`, and any data corruption affecting only the payload (leaving the subflow/PM counters untouched) is silently reported as PASS. Fixes: 8117dac3e7c3 ("selftests: mptcp: add invert check in check_transfer") Cc: stable@vger.kernel.org Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-5-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 473f1a5ab2abc98dd9e74b95b9c23c66c47535cc Author: Paolo Abeni Date: Mon Aug 3 18:16:40 2026 +0200 mptcp: reclaim forward-allocated memory on RX path errors commit 41b49a8b914ec7dcb03eae93fb27f3c464078644 upstream. After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped. Fixes: 9db5b3cec4ec ("mptcp: borrow forward memory from subflow") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-8-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9b46fba7528f58ca09eac67ec7d474ff1e9af066 Author: Bryam Vargas Date: Mon Jul 27 20:30:58 2026 -0500 selinux: reject a permission value exceeding the class permission count commit d14b5d0e97fccd27974fedc03b903408872907fd upstream. perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley [PM: tweak comment for line length] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 841aea4d5a25e16273d04cd07a74142b4687e03b Author: Bryam Vargas Date: Fri Jul 31 12:44:11 2026 -0500 selinux: reject an unclaimed class value in security_get_classes() commit 22b05fec62c0fe9864cfceb52f7d0f3a34d9b1dd upstream. security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 1b4ff94ae7c580c880291519fb0e3e2bd075beef Author: Bryam Vargas Date: Fri Jul 31 12:44:09 2026 -0500 selinux: do not cancel a policy conversion that never started commit e5c0235a3c4e9eb047a16cd02323fe4ecf2f570e upstream. sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes() fails, and that helper dereferences the outgoing policy to cancel its sidtab conversion. On the first policy load there is no outgoing policy: security_load_policy() returns early for that case, before it converts anything, and state->policy is still NULL. A first load that fails while building the selinuxfs tree therefore takes a NULL dereference in selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load. Skip the cancel when there is no old policy, mirroring the check security_load_policy() already makes before it converts. Cc: stable@vger.kernel.org Fixes: 02a52c5c8c3b ("selinux: move policy commit after updating selinuxfs") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit acd5b09be98fd38b7392307880156fb0452a7276 Author: Bryam Vargas Date: Mon Jul 27 20:30:59 2026 -0500 selinux: reject a class permission count below its inherited common commit 9a82dcd98b6e6e11cfd162410967951f12152528 upstream. security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 42a7107f99d86a7524c37f108047dfa3db096ab5 Author: Bryam Vargas Date: Fri Jul 31 12:44:12 2026 -0500 selinux: require every boolean value to be defined commit a93d37a09b863810653f93d371fb197457d59deb upstream. p_bools.nprim comes from the policy image independently of how many booleans follow it, and cond_index_bool() fills bool_val_to_struct[] at value - 1, so a count larger than the values present leaves NULL entries. Every user of that array then walks it by index and dereferences each entry: cond_evaluate_expr() on the access-vector path, security_get_bools() and security_get_bool_value() behind selinuxfs, and security_set_bools(). A sparse class value is absorbed by policydb_class_isvalid() and its siblings; booleans have no such predicate, and no consumer that could use one. Reject a boolean value that no boolean defines, once, where the array is built. Conforming policies define every boolean they declare and are unaffected. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 1a4c3ffe2a48b8023e744fda201afcc758a5b37f Author: Yizhou Zhao Date: Tue Aug 18 23:16:38 2026 +0300 ipvs: separate destination availability state commit cdcc4e46180df8161f4d2f3c6fd6beaf6990133d upstream. IPVS configuration paths update destination availability while connection accounting updates destination overload state. The two independent states share dest->flags, so their read-modify-write updates can race and lose one another. Keep OVERLOAD in flags, where the preceding patch serializes its updates with dst_lock, and move AVAILABLE to cflags. This keeps configuration- controlled availability out of the scheduler hot cacheline until a scheduler needs to check it. It also prevents availability updates from clobbering overload state. The destination status bits are not exposed through the IPVS sockopt or netlink interfaces, so keep their definitions in the internal IPVS header. Readers can still observe stale destination state; this does not provide a cross-field snapshot. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Link: https://lore.kernel.org/all/8913381c-1e02-35c7-0ec4-61de5a12fd35@ssi.bg/ Assisted-by: Claude-Code:GLM-5.2 Suggested-by: Julian Anastasov Signed-off-by: Yizhou Zhao Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso (cherry picked from commit cdcc4e46180df8161f4d2f3c6fd6beaf6990133d) [ Julian: Backport by removing the hunks from ip_vs_xmit.c ] Signed-off-by: Julian Anastasov Signed-off-by: Sasha Levin commit 9ff46bf75bfade72b4a7cdc3f7a1029951e584b0 Author: Liyuan Pang Date: Tue Aug 18 02:09:35 2026 +0000 ubi: fastmap: fix ubi->fm memory leak [ Upstream commit d133e30aabc7c8eb8206827f8fbe0f3679adb911 ] The problem is that scan_fast() allocate memory for ubi->fm and ubi->fm->e[x], but if the following attach process fails in ubi_wl_init or ubi_read_volume_table, the whole attach process will fail without executing ubi_wl_close to free the memory under ubi->fm. Fix this by add a new ubi_free_fastmap function in fastmap.c to free the memory allocated for fm. If SLUB_DEBUG and KUNIT are enabled, the following warning messages will show: ubi0: detaching mtd0 ubi0: mtd0 is detached ubi0: default fastmap pool size: 200 ubi0: default fastmap WL pool size: 100 ubi0: attaching mtd0 ubi0: attached by fastmap ubi0: fastmap pool size: 200 ubi0: fastmap WL pool size: 100 ubi0 error: ubi_wl_init [ubi]: no enough physical eraseblocks (4, need 203) ubi0 error: ubi_attach_mtd_dev [ubi]: failed to attach mtd0, error -28 UBI error: cannot attach mtd0 ================================================================= BUG ubi_wl_entry_slab (Tainted: G B O L ): Objects remaining in ubi_wl_entry_slab on __kmem_cache_shutdown() ----------------------------------------------------------------------------- Slab 0xffff2fd23a40cd00 objects=22 used=1 fp=0xffff2fd1d0334fd8 flags=0x883fffc010200(slab|head|section=34|node=0|zone=1|lastcpupid=0x7fff) CPU: 0 PID: 5884 Comm: insmod Tainted: G B O L 5.10.0 #1 Hardware name: LS1043A RDB Board (DT) Call trace: dump_backtrace+0x0/0x198 show_stack+0x18/0x28 dump_stack+0xe8/0x15c slab_err+0x94/0xc0 __kmem_cache_shutdown+0x1fc/0x39c kmem_cache_destroy+0x48/0x138 ubi_init+0x1d4/0xf34 [ubi] do_one_initcall+0xb4/0x24c do_init_module+0x4c/0x1dc load_module+0x212c/0x2260 __se_sys_finit_module+0xb4/0xd8 __arm64_sys_finit_module+0x18/0x28 el0_svc_common.constprop.0+0x78/0x1a0 do_el0_svc+0x78/0x90 el0_svc+0x20/0x38 el0_sync_handler+0xf0/0x140 normal+0x3d8/0x400 Object 0xffff2fd1d0334e68 @offset=3688 Allocated in ubi_scan_fastmap+0xf04/0xf40 [ubi] age=80 cpu=0 pid=5884 __slab_alloc.isra.21+0x6c/0xb4 kmem_cache_alloc+0x1e4/0x80c ubi_scan_fastmap+0xf04/0xf40 [ubi] ubi_attach+0x1f0/0x3a8 [ubi] ubi_attach_mtd_dev+0x810/0xbc8 [ubi] ubi_init+0x238/0xf34 [ubi] do_one_initcall+0xb4/0x24c do_init_module+0x4c/0x1dc load_module+0x212c/0x2260 __se_sys_finit_module+0xb4/0xd8 __arm64_sys_finit_module+0x18/0x28 el0_svc_common.constprop.0+0x78/0x1a0 do_el0_svc+0x78/0x90 el0_svc+0x20/0x38 el0_sync_handler+0xf0/0x140 normal+0x3d8/0x400 Link: https://bugzilla.kernel.org/show_bug.cgi?id=220744 Signed-off-by: Liyuan Pang Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 075036cea14aece52cfbb518f1761a40eeb975df Author: Cheng Ming Lin Date: Tue Aug 18 02:09:34 2026 +0000 mtd: ubi: skip programming unused bits in ubi headers [ Upstream commit 77530d1a78ca5c274e37d6494a965223672630b2 ] This patch prevents unnecessary programming of bits in ec_hdr and vid_hdr that are not used or read during normal UBI operation. These unused bits are typcially already set to 1 in erased flash and do not need to be explicitly programmed to 0 if they are not used. Programming such unused areas offers no functional benefit and may result in unnecessary flash wear, reducing the overall lifetime of the device. By skipping these writes, we preserve the flash state as much as possible and minimize wear caused by redundant operations. This change ensures that only necessary fields are written when preparing UBI headers, improving flash efficiency without affecting functionality. Additionally, the Kioxia TC58NVG1S3HTA00 datasheet (page 63) also notes that continuous program/erase cycling with a high percentage of '0' bits in the data pattern can accelerate block endurance degradation. This further supports avoiding large 0x00 patterns. Link: https://europe.kioxia.com/content/dam/kioxia/newidr/productinfo/datasheet/201910/DST_TC58NVG1S3HTA00-TDE_EN_31442.pdf Signed-off-by: Cheng Ming Lin Reviewed-by: Miquel Raynal Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit bb03b56d1d754908a37a160603be21769da423cf Author: Chao Shi Date: Mon Jul 27 16:12:57 2026 -0400 block: stop the timeout timer when releasing a never added disk [ Upstream commit 26cb8ebbfaf713c82e142d08828d4d765057633b ] disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme. Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260727201257.211635-1-coshi036@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e2c3337c2238e9e59711828f52182e02bc39c00a Author: Michael Diesen Date: Mon Jul 27 09:19:21 2026 +0000 ALSA: hda/realtek: Add quirk for HP Dragonfly Folio G3 2-in-1 (103c:8a05) [ Upstream commit bed0c8084044364f5ac3f3e89e1bbad423f6b0d4 ] The HP Dragonfly Folio G3 2-in-1 also ships with PCI SSID 103c:8a05. On this unit the ALC245 codec reports subsystem id 103c:8a06 - the SSID that is already covered by commit 0a10faad5ca5 ("ALSA: hda/realtek: add quirk for HP Dragonfly Folio G3 2-in-1") - while the PCI SSID that SND_PCI_QUIRK matches against is 103c:8a05: snd_hda_codec_alc269 ehdaudio0D0: ALC245: picked fixup for PCI SSID 103c:8a05 cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: CS35L41 Bound - SSID: 103C8A06 The existing entry therefore never applies here, the four CS35L41 amplifiers on SPI are not registered and the internal speakers stay silent. Add the same fixup that the 8a06 entry uses: the four amplifiers bind and the speaker mute LED (codec GPIO 0x04) works. Signed-off-by: Michael Diesen Link: https://patch.msgid.link/20260727091920.4634-1-michael.diesen@posteo.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e1e49f488a1c8ec021a37fbe5a7f32b1c5e13e14 Author: Alexandre Frade Date: Wed Aug 19 17:25:29 2026 +0000 Linux 6.18.45-xanmod1 Signed-off-by: Alexandre Frade commit 474774fc02c55efb35facaa1c57e7f0530032543 Merge: ad6ed82a8a85 bf3be28f6721 Author: Alexandre Frade Date: Wed Aug 19 17:24:03 2026 +0000 Merge tag 'v6.18.45' into 6.18 This is the 6.18.45 stable release commit bf3be28f6721e24961992ebb9e61c0cf21a56806 Author: Greg Kroah-Hartman Date: Wed Aug 19 18:18:21 2026 +0200 Linux 6.18.45 Link: https://lore.kernel.org/r/20260817132536.466235697@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Brett A C Sheffield Tested-by: Wentao Guan Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 1eb0dc458b6e8efc3a9cf02ec3ccd0f20576910e Author: Pablo Neira Ayuso Date: Thu Apr 30 16:49:48 2026 +0200 netfilter: flowtable: ensure sufficient headroom in xmit path commit ef4f741e8627512cb8c82f59a1fc7aacd854aadf upstream. Check for headroom and call skb_expand_head() like in the IP output path to ensure there is sufficient headroom for the mac header when forwarding this packet as suggested by sashiko. Fixes: b5964aac51e0 ("netfilter: flowtable: consolidate xmit path") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 99ec511f258e082fc7310990a6cf2023526ee7d6 Author: Lorenzo Bianconi Date: Mon Dec 1 11:22:45 2025 +0100 netfilter: always set route tuple out ifindex commit 2bdc536c9da7fa08baf0fafe9d91243b83cb9c8b upstream. Always set nf_flow_route tuple out ifindex even if the indev is not one of the flowtable configured devices since otherwise the outdev lookup in nf_flow_offload_ip_hook() or nf_flow_offload_ipv6_hook() for FLOW_OFFLOAD_XMIT_NEIGH flowtable entries will fail. The above issue occurs in the following configuration since IP6IP6 tunnel does not support flowtable acceleration yet: $ip addr show 5: eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:11:22:33:22:55 brd ff:ff:ff:ff:ff:ff link-netns ns1 inet6 2001:db8:1::2/64 scope global nodad valid_lft forever preferred_lft forever inet6 fe80::211:22ff:fe33:2255/64 scope link tentative proto kernel_ll valid_lft forever preferred_lft forever 6: eth1: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:22:22:33:22:55 brd ff:ff:ff:ff:ff:ff link-netns ns3 inet6 2001:db8:2::1/64 scope global nodad valid_lft forever preferred_lft forever inet6 fe80::222:22ff:fe33:2255/64 scope link tentative proto kernel_ll valid_lft forever preferred_lft forever 7: tun0@NONE: mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000 link/tunnel6 2001:db8:2::1 peer 2001:db8:2::2 permaddr a85:e732:2c37:: inet6 2002:db8:1::1/64 scope global nodad valid_lft forever preferred_lft forever inet6 fe80::885:e7ff:fe32:2c37/64 scope link proto kernel_ll valid_lft forever preferred_lft forever $ip -6 route show 2001:db8:1::/64 dev eth0 proto kernel metric 256 pref medium 2001:db8:2::/64 dev eth1 proto kernel metric 256 pref medium 2002:db8:1::/64 dev tun0 proto kernel metric 256 pref medium default via 2002:db8:1::2 dev tun0 metric 1024 pref medium $nft list ruleset table inet filter { flowtable ft { hook ingress priority filter devices = { eth0, eth1 } } chain forward { type filter hook forward priority filter; policy accept; meta l4proto { tcp, udp } flow add @ft } } Fixes: b5964aac51e0 ("netfilter: flowtable: consolidate xmit path") Signed-off-by: Lorenzo Bianconi Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 9977321835c7ae71d12a43bed7baa5bd514d01c3 Author: Xu Rao Date: Wed Jun 24 14:27:03 2026 +0800 thunderbolt: Fix bandwidth group reservation indexing commit d2ee4d47aacbd2ba456092eeec670dba35fde291 upstream. Valid bandwidth group IDs range from 1 through MAX_GROUPS, while Group ID 0 is reserved. tb_consumed_dp_bandwidth() uses the Group ID directly to index its local group_reserved[] array. The array currently has MAX_GROUPS entries, so its valid indices are 0 through MAX_GROUPS - 1. Group ID MAX_GROUPS therefore accesses one element past the end, and the final group's reserved bandwidth is not included when the array is summed. Give group_reserved[] MAX_GROUPS + 1 entries so direct Group ID indexing covers the reserved ID 0 and valid IDs 1 through MAX_GROUPS. Fixes: 52a4490e89d7 ("thunderbolt: Reserve released DisplayPort bandwidth for a group for 10 seconds") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 40d2ffb74094cf36edbe05855566a4c58b6ce808 Author: Bryam Vargas Date: Thu Jun 25 06:54:09 2026 -0500 thunderbolt: Bound the DROM dual link port number before indexing sw->ports commit d6764992f17b23d91ff93ce905ab53c2aa7191f0 upstream. tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an out-of-bounds tb_port pointer that is stored and later dereferenced. Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index. Fixes: cd22e73bdf5e ("thunderbolt: Read port configuration from eeprom.") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit ca33df36aa0143a1d04f57d2086020c12e7eddb7 Author: Qing Ming Date: Tue Aug 11 23:28:03 2026 +0800 sctp: clear new_transport when removing a peer commit beb33f8ee1ca83acddb2a5ae80f3d22ec550b4c3 upstream. sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on control_chunk_list. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state. The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel: BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197 Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops. Clear new_transport when its peer is removed, before it can be used to create the HEARTBEAT. Fixes: 6af29ccc223b ("sctp: Bundle HEAERTBEAT into ASCONF_ACK") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming Acked-by: Xin Long Link: https://patch.msgid.link/20260811152803.5629-1-a0yami@mailbox.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 07daf4f9750104960a1d60831b2353c0d41f35fb Author: Yuxiang Yang Date: Sun Aug 9 12:38:06 2026 +0800 sctp: fix use-after-free of cached ASCONF chunk commit 8c283e7b56adce00193837f3311b06662466fb21 upstream. addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer. However, sctp_asconf_queue_teardown() releases the cached chunk without clearing addip_last_asconf. During peer restart handling, sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes sctp_asconf_queue_teardown() while the association remains alive and leaves the pointer dangling. A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(), which accesses the stale chunk and passes it to sctp_process_asconf_ack(), causing a use-after-free and a second release. Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses timer_delete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after the purge and dereference NULL. Clear addip_last_asconf after releasing the cached chunk, and make sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding ASCONF remains. Fixes: a000c01e60e4 ("sctp: stop pending timers and purge queues when peer restart asoc") Cc: stable@vger.kernel.org Suggested-by: Xin Long Signed-off-by: Yuxiang Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260809043806.2768302-1-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2b3b5eec8b2c30ee237e3c31a6a38de9c39d804d Author: Baul Lee Date: Thu Jul 30 01:00:28 2026 +0900 sctp: keep chunk->transport in step with the list it is queued on commit 9f2cf069a9a72a2d6b97ca8b4c70e714aac99749 upstream. __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: if (chunk->tsn_gap_acked) { list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; } The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches tchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Acked-by: Xin Long Link: https://patch.msgid.link/20260729160028.54546-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3bd46d33e3fd568e15d4b6f08fbfff395b41208c Author: Xu Rao Date: Mon Aug 3 17:53:28 2026 +0800 scsi: scsi_debug: Negate wrapped memcmp() result commit c4f6916a99cf105c3ff340b6210fcbba3fa66b35 upstream. comp_write_worker() returns true when the compared data matches. memcmp() returns zero for equal data and non-zero for different data, so its result must be negated before it is stored in a bool. The first segment already uses !memcmp(), but the wrapped segment uses memcmp() directly, reversing the match result. Use !memcmp() there as well. Fixes: 38d5c8336e60 ("scsi_debug: add Report supported opcodes+tmfs; Compare and write") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Reviewed-by: John Garry Link: https://patch.msgid.link/E5AD42E9C0E18633+20260803095328.3445311-1-raoxu@uniontech.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a14e4ef1d90c3418f01b3b6b8fd3a40a0a208a10 Author: Chengfeng Ye Date: Sun Jul 19 23:22:07 2026 +0800 bpf, sockmap: Fix sk_redir use-after-free in send verdict commit a76624733730e541e4955fdecf506af2f6b20558 upstream. sk_psock_msg_verdict() takes a socket reference for psock->sk_redir. tcp_bpf_send_verdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcp_bpf_sendmsg_redir(). When apply_bytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer: CPU 0 CPU 1 sk_redir = psock->sk_redir apply_bytes remains nonzero release_sock(sk) lock_sock(sk) apply_bytes reaches zero psock->sk_redir = NULL release_sock(sk) tcp_bpf_sendmsg_redir(sk_redir) sock_put(sk_redir) tcp_bpf_sendmsg_redir(sk_redir) The final sock_put() can free sk_redir before CPU 0 dereferences it. KASAN reported: BUG: KASAN: slab-use-after-free in tcp_bpf_sendmsg_redir+0xf39/0x1020 Read of size 8 at addr ffff888108537090 by task poc/87 Call Trace: tcp_bpf_sendmsg_redir+0xf39/0x1020 tcp_bpf_sendmsg+0x977/0x1a50 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 85: sk_prot_alloc+0x56/0x210 sk_clone+0x6f/0x14b0 inet_csk_clone_lock+0x24/0x740 tcp_create_openreq_child+0x25/0x2710 tcp_v4_syn_recv_sock+0x10a/0xe00 Freed by task 0: __kasan_slab_free+0x43/0x70 slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 Last potentially related work creation: __sk_destruct+0x3da/0x540 sk_psock_destroy+0x81e/0xab0 process_one_work+0x63a/0x1070 Take a temporary socket reference while the source socket lock still protects psock->sk_redir, and drop it after tcp_bpf_sendmsg_redir() returns. This keeps each unlocked use independent of cached-verdict ownership. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Chengfeng Ye Reviewed-by: John Fastabend Reviewed-by: Emil Tsalapatis Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260719152207.2892156-1-nicoyip.dev@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit 3c6d4ffa0c6db1ba25a0d9d0677ed9fb2f158626 Author: Eric Biggers Date: Mon Aug 3 11:12:32 2026 -0700 fsverity: Fix silent truncation in bpf_get_fsverity_digest() commit 7c68ed5c5ad4c185ea9654f5d8ee36560277b7dd upstream. bpf_get_fsverity_digest() silently truncates the digest if the provided buffer is too small. This is a footgun, and it doesn't match the semantics of the equivalent UAPI (FS_IOC_MEASURE_VERITY). Change it to return -EOVERFLOW instead, matching FS_IOC_MEASURE_VERITY. Fixes: 67814c00de31 ("bpf, fsverity: Add kfunc bpf_get_fsverity_digest") Signed-off-by: Eric Biggers Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803181232.14743-3-ebiggers@kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit 2a5cfcad1d56e26d645b7887b0ed24c371851525 Author: Eric Biggers Date: Mon Aug 3 11:12:31 2026 -0700 fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions commit 3e8ec7c0387273329374f5c7bd61f5f38af71fe1 upstream. The BPF verifier and the dynptr abstraction ensure that the memory space referenced by a dynptr remains valid. They do not, however, provide any guarantee that the contents of the memory are stable. kfuncs are expected to remain memory-safe even if concurrent modifications occur. bpf_get_fsverity_digest() didn't follow that: it could crash if arg->digest_size was concurrently modified. Fix that by using the known-good value hash_alg->digest_size instead. Also widen 'dynptr_sz' and 'out_digest_sz' to u64 to match the return type of __bpf_dynptr_size(). It doesn't appear that it can actually be more than INT_MAX currently (since __bpf_dynptr_data_rw() excludes file-based pointers), but the correct type might as well be used. Fixes: 67814c00de31 ("bpf, fsverity: Add kfunc bpf_get_fsverity_digest") Signed-off-by: Eric Biggers Acked-by: Kumar Kartikeya Dwivedi Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803181232.14743-2-ebiggers@kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit 4917e3ebcab50f0265e8ca01c8567de4c4a47511 Author: Hugh Dickins Date: Mon Jul 27 22:24:14 2026 -0700 mm/filemap: __filemap_add_folio() restore index before retrying commit 86da3f7e1e609e1e8bfbab198af68467c5a015a5 upstream. In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly: each application modifies xas.xa_index, rounding it down according to the split_order attempted at that stage: and if all goes as intended, it eventually (or immediately) converges on an xas_try_split() to the required folio_order, with xas.xa_index now the same as index: then xas_store() puts the new folio into the xarray there. But if a new node was needed, and GFP_NOWAIT allocation did not get one, the lock is dropped, xas_nomem() used to allocate, and sequence retried. If (that part of) the xarray is unchanged when the lock is reacquired, no problem. But what if the conflict was meanwhile resolved by another thread (perhaps even doing the same thing, inserting a folio at that same index)? Isn't there a danger of now putting our folio into the xarray at an intermediate rounded-down index? With !folio_contains() bug to follow, when CONFIG_DEBUG_VM=y is checking for that. Fix this with an xas_set_order() to restore the original xas.xa_index at the bottom of the loop, so the retry does a full re-evaluation after reacquiring the lock, and cannot reach xas_store() with the wrong index. Production was suffering from rare SIGILLs and SIGSEGVs, executable text found a page away from where it belonged, !folio_contains() bug hit when debug enabled: symptoms not seen since this patch went in. Link: https://lore.kernel.org/562fbfa6-dd6d-0b6a-2461-ed2ff1173bc8@google.com Fixes: 200a89c159a7 ("mm/filemap: use xas_try_split() in __filemap_add_folio()") Signed-off-by: Hugh Dickins Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Zi Yan Cc: Chris J Arges Cc: David Hildenbrand Cc: Jan Kara Cc: Kairui Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit dd21c96a71e876c8df9ec546b885a2c5f47bbb05 Author: Mimi Zohar Date: Mon Jul 27 20:39:41 2026 -0400 ima: Instantiate file_truncate and path_truncate hooks commit b80bed5c871a80151351342c065579405ce77145 upstream. Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access. Tested-by: Frederick Lawler Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 102fb2dacf4500617be9bc2105c1ee6f17151455 Author: Tejun Heo Date: Sun Jul 12 07:23:55 2026 -1000 sched/psi: Create the psimon kthread outside of cgroup_mutex commit fadeedd7cfc5d73d33fa3d7ac54b9b27aabd09d2 upstream. a5b98009f16d ("sched/psi: fix race between file release and pressure write") made pressure_write() hold cgroup_mutex across psi_trigger_create(), which forks the psimon kthread for the first rtpoll trigger. As kthread creation depends on the whole fork path, the commit inadvertently created a lot of unwanted locking dependencies from cgroup_mutex. sched_ext got hit by one: its enable path blocks forks and then grabs cgroup_mutex, so a pressure write racing a scheduler enable deadlocks, with every other fork piling up behind. Fix it by splitting trigger creation so that the worker is forked with cgroup_mutex dropped and the kernfs active reference left broken. The latter matters because rmdir and cgroup.pressure writes drain active references under cgroup_mutex. Publishing the trigger last keeps error reporting synchronous and preserves the of->priv lifetime rules. The trigger registered in the first stage pins the group's rtpoll machinery across the unlocked window, leaving only creation races to resolve. The catch-up poll on installation covers scheduling attempts dropped while there was no worker. v2: Retagged sched/psi (was cgroup). Fixes: a5b98009f16d ("sched/psi: fix race between file release and pressure write") Cc: stable@vger.kernel.org Cc: Edward Adam Davis Cc: Chen Ridong Reported-by: Matt Fleming Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/ Signed-off-by: Tejun Heo Acked-by: Johannes Weiner Tested-by: Matt Fleming Acked-by: Suren Baghdasaryan Signed-off-by: Greg Kroah-Hartman commit 8037c5b2b2a447df52542f4d8535895d837bdcbd Author: Tejun Heo Date: Sun Jul 12 07:23:55 2026 -1000 sched/psi: Shut down rtpoll_timer in psi_cgroup_free() commit 5457025fa8ca3c0d2732109513de839e3e797190 upstream. psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath and can race psi_trigger_destroy() taking down the last rtpoll trigger under rtpoll_trigger_lock: psi_schedule_rtpoll_work() psi_trigger_destroy() rcu_read_lock(); task = rcu_dereference(rtpoll_task); rcu_assign_pointer(rtpoll_task, NULL); timer_delete(&rtpoll_timer); mod_timer(&rtpoll_timer, ...); rcu_read_unlock(); synchronize_rcu(); kthread_stop(task_to_destroy); The group can then be freed with the re-armed timer still pending, and poll_timer_fn() runs on freed memory. 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling mechanism") deleted the timer synchronously after the synchronize_rcu(), which prevented this but raced trigger creation instead: the deletion could cancel the timer that a new trigger set armed during the grace period and, as creation also reinitialized the timer at the time, corrupt it. 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the initialization into group_init() and the deletion into the locked section, trading the creation races for the window above. Neither placement in the destruction path works. A pending timer firing while the group is alive is harmless though. poll_timer_fn() just wakes the rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it by then. timer_shutdown_sync() because the timer is never armed again. Fixes: 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") Cc: stable@vger.kernel.org # v5.10+ Reported-by: Sashiko AI Closes: https://lore.kernel.org/all/20260711000434.36C4A1F000E9@smtp.kernel.org/ Signed-off-by: Tejun Heo Acked-by: Johannes Weiner Tested-by: Matt Fleming Acked-by: Suren Baghdasaryan Signed-off-by: Greg Kroah-Hartman commit 653e888a24c87b8bbeab44d7e558a1c1a3641088 Author: Zhan Xusheng Date: Sat Jul 25 16:00:04 2026 +0800 fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() commit cf6c993c0feca7984797e634deba3c80342e199a upstream. fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead. Fixes: 14f3db5542e6 ("ext4: support idmapped mounts") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Link: https://patch.msgid.link/20260725080004.929328-1-zhanxusheng1024@gmail.com Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 4eb15c465337b18f44716c499cd6ad63eee0ad54 Author: Zhiling Zou Date: Mon Aug 3 14:12:33 2026 +0800 ip6_tunnel: clear skb2->cb[] in ip6ip6_err() commit f803c086399da277b5d0ff36a107d0f162751800 upstream. ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb. If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info. Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack. Fixes: e490d1d85cf5 ("[IPV6] IP6TUNNEL: Split out generic routine in ip6ip6_err().") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/fe1a5e765fbca88d69391887f0ed26a19e3e4d39.1785736562.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3b2231e358d26e3aec5d8040b1fb777af03c5f05 Author: Yuejie Shi Date: Thu Jul 30 11:52:32 2026 +0800 ipv6: fix Route Information option length validation commit d1ad8fb2ac6a1afb71dc22d9ae8efb4dda96c824 upstream. rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow. Fixes: 70ceb4f53929 ("[IPV6]: ROUTE: Add experimental support for Route Information Option in RA (RFC4191).") Cc: stable@vger.kernel.org Signed-off-by: Yuejie Shi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260730035310.74584-1-syjcnss@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7f740664aec1f832953c2e6d9b8920cd6c8bcc0c Author: Lorenzo Stoakes (ARM) Date: Thu Jul 23 16:16:34 2026 +0100 mm/ptdump: always stabilise against page table freeing using init_mm commit 27c32e5538344b13c1505a08861e04620c125d47 upstream. Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table"), so we target this in the Fixes tag. Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-4-8cc77dcc0018@kernel.org Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Cc: Andy Lutomirski Cc: "Borah, Chaitanya Kumar" Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Dave Hansen Cc: David Carlier Cc: Dev Jain Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Liam R. Howlett Cc: Michal Hocko Cc: Peter Zijlstra Cc: Ryan Roberts Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Toshi Kani Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5b926fb04cb9ef3156dcf88c69a59d3d1a1c4f9f Author: Tengda Wu Date: Mon Aug 3 00:56:39 2026 +0000 ring-buffer: Use current_context for safe per-CPU buffer swap commit f27bdc43077e4fcb5557dfc315ee8d91e741f483 upstream. The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap. Cc: stable@vger.kernel.org Fixes: 4239c38fe0b3 ("ring-buffer: Process commits whenever moving to a new page.") Link: https://patch.msgid.link/20260803005640.2445666-2-wutengda@huaweicloud.com Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2e37f2bf111429fbfa4d985b12df3ba496ca70aa Author: Vincent Donnefort Date: Thu Aug 6 22:13:03 2026 +0100 ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer() commit 6d014e44b68ddd43f71288d2a4dbb1a259869149 upstream. In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order). Cc: stable@vger.kernel.org Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Link: https://patch.msgid.link/20260806211306.3704194-4-vdonnefort@google.com Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5fd91dd4a143479b0575fb1f202ec1c501e71fd5 Author: Ahmad Byagowi Date: Tue Aug 4 14:07:51 2026 -0700 ptp: ocp: Fix board ID over-read commit 6b69f2ef10cdb018c0b127a7cab88e590bbddba4 upstream. The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan. Fixes: 0cfcdd1ebcfe ("ptp: ocp: add nvmem interface for accessing eeprom") Cc: stable@vger.kernel.org Signed-off-by: Ahmad Byagowi Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260804210751.48248-1-ahmadexp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8d34019d1413629a434a7e8d9f91c76d256196a0 Author: Rafael J. Wysocki Date: Tue Aug 4 22:09:10 2026 +0200 Revert "thermal/drivers/hwmon: Cleanup coding style a bit" commit ff8da20b6f47c48d46e47f93f7a59e2d56ee9107 upstream. Revert commit 030a48b0f6ce ("thermal/drivers/hwmon: Cleanup coding style a bit") that introduced a use-after-free into the error path of thermal_add_hwmon_sysfs() by removing a valid check from it. Link: https://lore.kernel.org/linux-hwmon/20260803183915.4ED7D1F000E9@smtp.kernel.org/ Cc: All applicable Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/5123895.31r3eYUQgx@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit 5635211b44969f4816e29ec4d5f8665fb39535d0 Author: Shuangpeng Bai Date: Wed Aug 5 22:27:19 2026 -0400 eventfs: Fix use-after-free in eventfs_remove_rec() commit fd73b691702170d37d66f4b0278530cea8ed419a upstream. eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running. Use list_for_each_entry_safe() to save the next sibling before recursively removing the current child. Cc: stable@vger.kernel.org Fixes: 43aa6f97c2d0 ("eventfs: Get rid of dentry pointers without refcounts") Link: https://patch.msgid.link/20260806022719.375354-1-shuangpeng.kernel@gmail.com Signed-off-by: Shuangpeng Bai Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 66bc868a33cf1de43f22a94acd8857e0fe33393f Author: Sean Christopherson Date: Mon Jul 13 08:25:49 2026 -0700 KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page commit 5ec42d57655c690234c14aece6dd3f209778c1d8 upstream. Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to __kvm_mmu_prepare_zap_page() using list_add() instead of list_move() when processing an invalid shadow page, i.e. makes a bad situation far worse. Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page. ================================================================== BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853 CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4b/0x70 print_report+0x153/0x49c kasan_report+0xbc/0xf0 __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] mmu_alloc_root+0x141/0x320 [kvm] kvm_mmu_load+0x612/0x20f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Allocated by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x5f/0x70 kmem_cache_alloc_noprof+0xfe/0x2e0 __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm] paging64_page_fault+0x318/0x1e30 [kvm] kvm_mmu_do_page_fault+0x21d/0x630 [kvm] kvm_mmu_page_fault+0x18c/0x17b0 [kvm] kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free+0xe2/0x400 kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm] kvm_mmu_free_roots+0x283/0x560 [kvm] kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Reported-by: Hyunwoo Kim Fixes: a770f6f28b1a ("KVM: MMU: Inherit a shadow page's guest level count from vcpu setup") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 47976eaaf0a4eb46dade48b3246779090db9e3ec Author: Paolo Bonzini Date: Thu Aug 6 16:44:17 2026 +0200 KVM: SVM: Serialize accesses to the owner and mirror list with separate lock commit 1d78d33275ef2a16c6d080910b291d0a97a0e613 upstream. Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock. Fixes: b2125513dfc0 ("KVM: SEV: Allow SEV intra-host migration of VM with mirrors") Cc: stable@vger.kernel.org Reported-by: Shen Yongchao Link: https://lore.kernel.org/kvm/tencent_625C0F42824E542C72B34733392AF2C49709@qq.com/ Link: https://lore.kernel.org/kvm/tencent_DDC4E4352EC91CAC05A9A8F4E55E8C96730A@qq.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1ffacbadc14530e55b8d86f7b917524f6a0fb891 Author: Shuangpeng Bai Date: Sat Aug 1 20:48:09 2026 -0400 smb: client: Fix use-after-free in cifs_try_adding_channels() commit 4986410316b1ae0e63c6ce418e4eb196723626e7 upstream. cifs_try_adding_channels() takes a temporary reference to an interface before dropping iface_lock. If cifs_ses_add_channel() fails, it drops that reference and then increments iface->weight_fulfilled. A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path kref_put() releases the last reference and frees iface. Updating weight_fulfilled afterward then accesses freed memory. Increment weight_fulfilled before dropping the temporary reference, keeping iface alive for the final access. Fixes: 6aac002bcfd5 ("cifs: failure to add channel on iface should bump up weight") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c3f2347a47754eac690967cfd82cb6d559817b07 Author: Jun Yang Date: Mon Aug 10 18:21:38 2026 +0800 tipc: read le->link under the node lock in tipc_node_link_down() commit cba9ccb47e9fa4cc77692fb896cc5ab57a667882 upstream. tipc_node_link_down() caches the link pointer before taking n->lock: struct tipc_link *l = le->link; /* unlocked */ if (!l) return; tipc_node_write_lock(n); if (!tipc_link_is_establishing(l)) { /* deref l */ ... tipc_link_reset(l); /* write into l */ if (delete) { kfree(l); le->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL. Fixes: 73f646cec354 ("tipc: delay ESTABLISH state event when link is established") Cc: stable@kernel.org Reported-by: TencentOS Corvus AI Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260810102147.48191-1-juny24602@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3fc5044796dd87b8d68be4207046f5ce2748174c Author: chanyoung Date: Tue Aug 4 14:28:35 2026 +0900 tls: don't leave a full plaintext sk_msg ring unpushed commit 7bca91d63341274e857f4aeaad54d229405e93dc upstream. When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the "tls" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop. Suggested-by: Sabrina Dubroca Fixes: fe1e81d4f73b ("tls/sw: Support MSG_SPLICE_PAGES") Cc: stable@vger.kernel.org Signed-off-by: chanyoung Link: https://patch.msgid.link/20260804052837.49015-2-ppoo1220@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 68787940274ec89f41dc91b1a68ee1a16a90735f Author: Jérémy Jean Date: Tue Aug 4 12:55:28 2026 +0000 tls: rx: restore msg_iter before TLS 1.3 optimistic retry commit 1c8629651cb54f7b51db8fc0b1a9944e4a4b0f5e upstream. tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced. The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD. Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy. Add a selftest which sends a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length. Fixes: ce61327ce989 ("tls: rx: support optimistic decrypt to user buffer with TLS 1.3") Cc: stable@vger.kernel.org Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260804125528.2139928-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f1e21108e3ddfcce62f6cad4ebd7b5674543c9e6 Author: Jun Yang Date: Mon Aug 3 09:45:14 2026 +0800 vhost: reset the vring metadata cache on vring reconfiguration commit de845981da67a6b049080c87e605130b0c30adc5 upstream. vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: if (vhost_vq_meta_fetch(vq, addr, len, type)) return true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as map->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path. Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache") Cc: stable@vger.kernel.org Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang Message-ID: <20260803014823.68623-1-juny24602@gmail.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit cdf745b7a777f87f51666e5d8f4c6fc279bcf54d Author: Sun Jian Date: Mon Aug 3 22:40:39 2026 -0700 veth: fix skb length accounting after XDP frag adjustment commit cb6379feaaff11c4e1e79c26c745ffa23182768a upstream. veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present. The skb is then still non-linear, so the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT(). Use skb_set_tail_pointer() and update skb->len explicitly instead, following bpf_prog_run_generic_xdp(). Unlike __skb_put(), skb_set_tail_pointer() does not require a linear skb. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpf_xdp_pull_data() with frags still present; the old code triggers SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs. Fixes: 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order to accept non-linear skb") Cc: stable@vger.kernel.org Reported-by: Mohsin Bashir Link: https://lore.kernel.org/bpf/80687d9c-9c27-494c-b3f2-efd0230b1895@gmail.com/ Suggested-by: Lorenzo Bianconi Acked-by: Lorenzo Bianconi Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260804054040.613675-3-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 38c7763fdc533edb34dc8f4489c260e8ba2ccae9 Author: Weiming Shi Date: Wed Jul 29 12:16:55 2026 -0700 vsock/virtio: avoid refilling the RX queue after teardown commit a31e0ad444698d8aa7534a0f89fda543730f97a5 upstream. Commit b917507e5ad9 ("vsock/virtio: stop workers during the .remove()") made the RX worker jump to its common exit when rx_run is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtio_vsock_vqs_del() can add buffers after the virtqueues have been deleted. BUG: KASAN: slab-use-after-free in virtqueue_add_sgs Read of size 4 by task kworker/0:1 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2796) virtio_vsock_rx_fill (net/vmw_vsock/virtio_transport.c:332) virtio_transport_rx_work (net/vmw_vsock/virtio_transport.c:701) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3478) 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) ... Freed by task 141: kfree (mm/slub.c:6566) vp_del_vq (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtio_vsock_freeze (net/vmw_vsock/virtio_transport.c:912) virtio_device_freeze (drivers/virtio/virtio.c:658) virtio_pci_freeze (drivers/virtio/virtio_pci_common.c:601) pci_pm_freeze (drivers/pci/pci-driver.c:1098) device_suspend (drivers/base/power/main.c:1968) Kernel panic - not syncing: KASAN: panic_on_warn set ... Jump to a no-refill exit when rx_run is clear, leaving the normal exit to replenish a running queue. Fixes: b917507e5ad9 ("vsock/virtio: stop workers during the .remove()") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Link: https://lore.kernel.org/r/20260727035804.1860862-1-bestswngs@gmail.com Suggested-by: Stefano Garzarella Signed-off-by: Weiming Shi Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/f9c8c1d64cad9d262f305d02ffe164c2f900fadf.1785352330.git.bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bd43a7ec668be428265b3209eb43647aedcf720a Author: Weiming Shi Date: Wed Jul 29 12:16:54 2026 -0700 vsock/virtio: read virtqueues under worker locks commit ebac8f6b1ef0e9278afe204b8692a7479988dace upstream. Commit bd50c5dc182b ("vsock/virtio: add support for device suspend/resume") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue. Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation. Fixes: bd50c5dc182b ("vsock/virtio: add support for device suspend/resume") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Link: https://lore.kernel.org/r/20260727035804.1860862-1-bestswngs@gmail.com Signed-off-by: Weiming Shi Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/e79f68ad9284c983364fc3ac46904b6d9ef50231.1785352330.git.bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 46bb297ad77680e009244f067f27d51cf5b8c7cf Author: Baul Lee Date: Sun Aug 9 20:18:29 2026 +0900 vxlan: do not arm the ageing timer on a device that is down commit b37971686ec59fb027fa4910ba16805e68fddb97 upstream. vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: if (conf.age_interval != vxlan->cfg.age_interval) mod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee Fixes: 40051c4dcad5 ("vxlan: Allow changing ageing time") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260809111829.78834-1-baul.lee@xbow.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit fab820f1691a9e26d9031f18aae1e9ce09078f92 Author: Zhiling Zou Date: Mon Aug 3 20:15:32 2026 +0800 xdp: reject clones that overrun skb_shared_info tailroom commit e48e8edbef2eb824201495daa5234560f632b23c upstream. xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/6b2afef5d1738763c6965e8e466eb16e43e4f956.1785757386.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e708fc1566ebd4a2d3f2546e6310d64d362db80d Author: Breno Leitao Date: Mon Aug 3 02:47:40 2026 -0700 x86/mce: Set up the polling timer before CMCI discovery commit a213dfaa2596c1c0dc4dae91c14fbfa499c03223 upstream. I hit the following on one of my machines: mce: CPU0 BANK15 CMCI inherited storm ------------[ cut here ]------------ ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0 WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY RIP: 0010:debug_object_assert_init+0x18f/0x230 Call Trace: __mod_timer mce_timer_kick cmci_discover intel_init_cmci mce_intel_feature_init mcheck_cpu_init identify_cpu identify_boot_cpu arch_cpu_finalize_init start_kernel A second splat follows right after, from timer_setup() finding that same timer already queued: ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10 This is happening because CMCI storm detection is trying to modify the timer before latter was properly set up. Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(), and depends on neither the generic nor the vendor init. [ bp: Massage commit message. ] Fixes: 1f68ce2a0272 ("x86/mce: Handle Intel threshold interrupt storms") Signed-off-by: Breno Leitao Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260803-mce_timer_init-v1-1-9539db424330@debian.org Signed-off-by: Greg Kroah-Hartman commit 846b92e26c8ab72eb706a1e5e43a3adedee59fda Author: Rik van Riel Date: Thu Aug 6 08:54:57 2026 -0700 x86/CPU: Add a tlbi= cmdline switch commit abe7c8b09bd72a9c726016257c6281f129b4c02d upstream. With the recently found INVLPGB / TLBSYNC issue, there has been some interest in disabling INVLPGB-based TLB flushing, in order to rule out that CPU issue as a cause of userspace crashes. Add a kernel command line option to control the TLB flushing behavior. If the need arises, we will add a "tlbi=broadcast" for the case when TLB invalidation broadcasts need to be explicitly selected, but this is not needed now yet. [ bp: Rewrite commit message, move to cpu/common.c, add documentation. ] Fixes: 767ae437a32d ("x86/mm: Add INVLPGB feature and Kconfig entry") Suggested-by: Borislav Petkov Signed-off-by: Rik van Riel Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://patch.msgid.link/20260729204341.3eb0b5ea@fangorn Signed-off-by: Greg Kroah-Hartman commit 69298af46f39777174771be7108661504ba78ff3 Author: Lorenzo Stoakes (ARM) Date: Thu Jul 23 16:16:35 2026 +0100 arm64: remove redundant concurrent ptdump UAF mitigation commit 9d3277b2c07ccc9508d648098b3bbb46c61b7f3c upstream. This partially reverts commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), retaining vmalloc-huge support but eliminating the now redundant mitigation against a race between huge vmap page table freeing and ptdump, as this issue has now been fixed at core. We also simultaneously remove the arm64 if-deffery when acquiring the mmap read lock upon vmap huge page table promotion as it is no longer required. Note that this patch relies on the preceding vmalloc patch, and should not be backported alone. Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-5-8cc77dcc0018@kernel.org Fixes: fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump") Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Dev Jain Acked-by: Mike Rapoport (Microsoft) Acked-by: Kiryl Shutsemau (Meta) Acked-by: Will Deacon Reviewed-by: David Hildenbrand (Arm) Cc: Andy Lutomirski Cc: "Borah, Chaitanya Kumar" Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Dave Hansen Cc: David Carlier Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Liam R. Howlett Cc: Michal Hocko Cc: Peter Zijlstra Cc: Ryan Roberts Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Toshi Kani Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fe79571f40434b257d68cbfb7b3ae93a794d8a11 Author: Hidayath Khan Date: Thu Jul 30 14:42:27 2026 +0200 dibs: initialise dibs->lock in dibs_dev_alloc() commit c27e360545373b7aee9862a5beef3b9fb3df0c25 upstream. dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else. Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler. Fixes: cc21191b584c ("dibs: Move data path to dibs layer") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter Signed-off-by: Hidayath Khan Link: https://patch.msgid.link/20260730124227.167829-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a2e326c52c4bcecc033cd3ca2733fdbe30fbf55d Author: Asad Kamal Date: Thu Jul 30 15:00:00 2026 +0800 Revert "drm/amdgpu: fix aperture mapping leak" commit b96c529cd2551b78316a4afa3237b2ed96ba03c8 upstream. devres teardown is LIFO. The aperture devres node was registered after the DRM device node, so devres_release_all() unmaps the aperture before the DRM device release callback fires amdgpu_device_fini_sw(). IP sw_fini callbacks (e.g. vcn_v4_0_sw_fini) write to fw_shared through a pointer derived from aper_base_kaddr, causing a kernel page fault on probe failure / rollback: BUG: unable to handle page fault ... PMD 0 RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu] Call Trace: amdgpu_device_fini_sw amdgpu_driver_release_kms devm_drm_dev_init_release devres_release_all This reverts commit d871e99879cb5fd1fa798b006b4888887e63a17a. Fixes: d871e99879cb ("drm/amdgpu: fix aperture mapping leak") Reported-by: Yuansheng Mao Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 24e95a24f151ce40d5fc1b3a6cefbcda8ded736c Author: Christian Brauner Date: Sun Aug 2 20:00:44 2026 +0200 binfmt_misc: don't warn when the mount is completed from another user namespace commit 79fdf39f1a31f88cb3833b6f8091fbf6acdca2c6 upstream. fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen("binfmt_misc") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns. Fixes: 21ca59b365c0 ("binfmt_misc: enable sandboxed mounts") Cc: stable@vger.kernel.org # v6.7+ Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-2-4e987911a39a@kernel.org Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit be161fa31e3e9cc828a3c1bd935edca461e8a7a1 Author: Christian Brauner Date: Sun Aug 2 20:00:43 2026 +0200 ovl: don't warn when the mount is completed from another user namespace commit 63981fc786daaa626cb14d9be1406f674d79f98f upstream. fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen("overlay") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds. Fixes: 1784fbc2ed9c ("ovl: port to new mount api") Cc: stable@vger.kernel.org # v6.5+ Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-1-4e987911a39a@kernel.org Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 92f00f1d4d204a428b38e26fce3baee144b6955d Author: Hyunjung Ko Date: Thu Aug 6 19:12:52 2026 +0900 net/sched: act_gact, act_police: range check the fallback control action commit 883b56ae58fe657d8497806c7059646e9ba6dbd0 upstream. tcf_action_check_ctrlact() range checks the primary control action: if (!opcode) ret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after both goto-chain guards were written: commit 9469f375ab09 ("net/sched: act_gact: disallow 'goto chain' on fallback control action") and commit c08f5ed5d625 ("net/sched: act_police: disallow 'goto chain' on fallback control action"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none. Fixes: 720f22fed81b ("net: sched: refactor reinsert action") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Hyunjung Ko Acked-by: Jamal Hadi Salim Tested-by: Victor Nogueira Link: https://patch.msgid.link/20260806101252.809593-1-hj351016@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b47bb899e04b5407c5a63fe88d4b6676586a6e84 Author: Hyunjung Ko Date: Thu Aug 6 19:12:34 2026 +0900 net/sched: act_ct: fix sk_buff leak when the header checks reject a packet commit 8a7ed561671aa6a911a2de99e59ef670a4d0b1df upstream. tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: if (family == NFPROTO_IPV4) err = tcf_ct_ipv4_is_fragment(skb, &frag); else err = tcf_ct_ipv6_is_fragment(skb, &frag); if (err || !frag) return err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: err = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); if (err) goto out_frag; ... out_frag: if (err != -EINPROGRESS) tcf_action_inc_drop_qstats(&c->common); return TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with "action ct". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none. Fixes: 3f14b377d01d ("net/sched: act_ct: fix skb leak and crash on ooo frags") Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Hyunjung Ko Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260806101235.809370-1-hj351016@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 782cc40b7ade4614a8aec0b948b8cf95c69f8d4b Author: Yangyu Chen Date: Sun Aug 2 23:46:38 2026 +0800 net: atlantic: free RX pages of consumed but not refilled buffers commit e8e7471ef686b6c002218fee9671cc61992ae01a upstream. aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path. Cc: stable@vger.kernel.org # v5.2+ Fixes: 46f4c29d9de6 ("net: aquantia: optimize rx performance by page reuse strategy") Reviewed-by: Sukhdeep Singh Signed-off-by: Yangyu Chen Acked-by: Mina Almasry Link: https://patch.msgid.link/tencent_607CBA8237DA438E36B844318B21538DE008@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b13202d401e1a20fec89b0cda733dcbaf279f79d Author: Yangyu Chen Date: Sun Aug 2 23:46:00 2026 +0800 net: atlantic: free stranded TX buffers on ring deinit commit 452636ea5410a96e02ebaaf80b21e3620b98e0dd upstream. aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and "page_pool_release_retry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context. Fixes: eb36bedf28be ("net: aquantia: remove function aq_ring_tx_deinit") Cc: stable@vger.kernel.org # v4.11+ Reviewed-by: Sukhdeep Singh Signed-off-by: Yangyu Chen Acked-by: Mina Almasry Link: https://patch.msgid.link/tencent_EEDC35FAF2750A3A6A0B39BAE0E2C484860A@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0424186d570aa4d1ad17f516afb86bd9eaa4f42e Author: Zihan Xi Date: Sat Aug 1 14:27:17 2026 +0000 netfilter: nf_conntrack: defer invalid log until after unlock commit 2d19b95c9723001f214f7a47d67b09f46238f200 upstream. TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held. When invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock. Defer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking. Do the same for the SCTP invalid state-transition log that can be reached while ct->lock is held. Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well. Fixes: 628d694344a0 ("netfilter: conntrack: reduce timeout when receiving out-of-window fin or rst") Fixes: d9a6f0d0df18 ("netfilter: conntrack: prepare tcp_in_window for ternary return value") Fixes: f71cb8f45d09 ("netfilter: conntrack: sctp: use nf log infrastructure for invalid packets") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit c58d34fe8b7e47bb0b350a7625023b1261342be5 Author: Zhiling Zou Date: Fri Jul 31 14:36:53 2026 +0800 netfilter: bridge: release template ct on non-IP path commit d45cc8020d7c0a9f01dee42ff5c40bc14c9af72f upstream. A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path. Fixes: 3c171f496ef5 ("netfilter: bridge: add connection tracking system") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e9bfe12b1d04c34c6fedcba21d9709b65c08aa33 Author: Pavel Begunkov Date: Mon Jul 27 12:19:37 2026 +0100 net: devmem: prevent net-iov / page mixing commit 53a43508ee332d8bffe40590c3d189c92a551f9f upstream. We should either have net_iov or page backed frags in a single skb, otherwise it blows up down the stack. Don't allow mixing in zerocopy_fill_skb_from_devmem(). Fixes: bd61848900bff ("net: devmem: Implement TX path") Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Acked-by: Stanislav Fomichev Reviewed-by: Mina Almasry Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/e3199788c4732545627a4721097ebb71ad737bab.1785150502.git.asml.silence@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4bc522b33438fefc3272840ae5988771863a4f1f Author: Baul Lee Date: Mon Jul 27 07:03:42 2026 +0900 net/x25: fix use-after-free of the socket by its timers commit 2195424c3da2ef1829a63b807e3a900a90e57d85 upstream. The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726220342.47245-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ece6426b61241e9bfb41aa131f235168f55229b1 Author: Alexandra Winter Date: Mon Aug 10 13:14:32 2026 +0200 net/dibs: Correct freeing of dmb_clientid_arr commit 9e6869be49064915edb6c8776b27c376cfdb0df5 upstream. A dibs device interrupt handler can be active after dibs_dev_del() and may still access dmb_clientid_arr. (UAF) In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe() dmb_clientid_arr is freed twice (double free). Free dmb_clientid_arr in dibs_dev_release() after last reference is gone. Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok for now, because no dmbs can be registered before dibs_dev_add(). Fixes: cc21191b584c ("dibs: Move data path to dibs layer") Cc: stable@vger.kernel.org Co-developed-by: Hidayath Khan Signed-off-by: Hidayath Khan Signed-off-by: Alexandra Winter Reviewed-by: Dust Li Link: https://patch.msgid.link/20260810111432.2334900-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 680fbd7942185448eadb990a3d10a53eb946b702 Author: Kyle Zeng Date: Mon Aug 3 12:27:57 2026 +0000 ipv6: prevent in6_dev_get() from resurrecting inet6_dev commit 0e243671bc7b8eaf00f83dd2f4367436dc0cff98 upstream. in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000: refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0 It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends: BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219 Bug found and triaged by OpenAI Security Research and validated by Trail of Bits. Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260803122758.666112-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0b7d54cedea5cb158e21925ae0c6c2f5c87ed2a0 Author: Daming Li Date: Thu Jul 30 22:55:52 2026 +0800 net: smc: fix splice entry lifetime imbalance in smc_rx_splice commit 5d9686af2976741bbd79b150d1c9e60b81e7f12e upstream. smc_rx_splice() passes pages to splice_to_pipe() before taking the references that cover the lifetime of each splice entry. In the VM-backed RMB path, splice_to_pipe() may drop unqueued entries through smc_rx_spd_release(), while queued entries are released later via the pipe buffer callback. The old post-splice accounting also derives the number of queued VM pages from an offset mutated while building the descriptor, and a multi-page splice pairs one sock_hold() with multiple sock_put() calls. Take the page and socket references for every candidate entry before splice_to_pipe(), and drop the matching private state, page reference, and socket reference from smc_rx_spd_release() for entries that never get queued. This fixes a refcount imbalance that can underflow page refcounts and trigger a use-after-free. Fixes: 9014db202cb7 ("smc: add support for splice()") Cc: stable@vger.kernel.org Reported-by: Vega Co-developed-by: Xiao Liu Signed-off-by: Xiao Liu Signed-off-by: Daming Li Signed-off-by: Ren Wei Reviewed-by: Dust Li Reviewed-by: Sidraya Jayagond Link: https://patch.msgid.link/20260730145552.360287-2-enjou1224z@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b65c11bc62216ac10f52c5bb41911d8728508ff3 Author: Ahmed Naseef Date: Tue Aug 4 15:35:11 2026 +0400 net: phy: mediatek: fix TX blink masks using the RX bits commit f684c514f7965385dae21f2535f99938e73ec1af upstream. MTK_GPHY_LED_TX_BLINK_SET and MTK_2P5GPHY_LED_TX_BLINK_SET are built from the RX blink bits instead of the TX ones, so both TX masks are identical to their RX counterparts. The TX bits they should be using, MTK_PHY_LED_BLINK_{10,100,1000,2500}TX, are otherwise only referenced by the per-speed branch of mtk_phy_led_hw_ctrl_set(). A TX trigger selected without a link trigger therefore programs the RX blink bits, and the LED blinks on received traffic. The masks are also used to decode the blink register in mtk_phy_led_hw_ctrl_get(), which as a result cannot tell the two triggers apart: an RX-only configuration reads back as RX and TX, and a TX-only configuration reads back as neither. Fixes: 7f9c320c98db ("net: phy: mediatek: Move LED helper functions into mtk phy lib") Cc: stable@vger.kernel.org Signed-off-by: Ahmed Naseef Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260804113511.3371248-1-naseefkm@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 105d04edbec83010df5728f74d17fd9c108e7553 Author: Lorenzo Stoakes (ARM) Date: Thu Jul 30 11:55:47 2026 +0100 mm/huge_memory: fix huge_zero_pfn race commit 33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb upstream. Patch series "mm/huge_memory: fix huge_zero_pfn race", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and huge_zero_refcount writes. * Be set non-zero only AFTER huge_zero_[pfn, folio] are set to valid values so installation of the huge zero folio on read page fault ensures concurrent is_huge_zero_*() calls correctly identify the huge zero folio. * Be set zero only BEFORE huge_zero_[pfn, folio] are set to NULL and ~0UL respectively, and atomically. Establish these by: * Only setting huge_zero_refcount to zero or an absolute value in the huge_zero_lock critical section in get_huge_zero_folio() and shrink_huge_zero_folio_scan(), and always updating atomically there and elsewhere. * Using atomic_set_release(&huge_zero_refcount) in get_huge_zero_folio() after huge_zero_[pfn, folio] are set. This is paired with atomic_inc_not_zero() to ensure atomic_inc_not_zero() only observes a non-zero value if huge_zero_[pfn, folio] are set. * Using atomic_cmpxchg() in shrink_huge_zero_folio_scan() (as before) to ensure that it is set zero only when equal to 1 and set atomically. * atomic_cmpxchg() being fully ordered ensures this is done prior to huge_zero_[folio, pfn] being set to NULL and ~0UL respectively. Eliminate the retry loop in get_huge_zero_folio() as the atomic_cmpxchg() in shrink_huge_zero_folio_scan() is now performed under the lock, and replace with an equally locked atomic_inc() to set the reference count should the caller be raced on huge zero folio installation. folio_put() naturally implies a full memory barrier so its ordering is maintained correctly. The huge zero folio also cannot be released except when the shrinker does so as it is non-LRU and non-rmappable. Note that only the huge zero shrinker (via shrink_huge_zero_folio_scan()) can actually set huge_zero_refcount to zero, which is the count of mm's which have at least one huge zero folio installed plus one shrinker pin. Additionally convert a BUG_ON() to a VM_WARN_ON_ONCE(). Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-0-c5d8a41b317f@kernel.org Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-1-c5d8a41b317f@kernel.org Fixes: 3b77e8c8cde5 ("mm/thp: make is_huge_zero_pmd() safe and quicker") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: Hengbin Zhang Closes: https://lore.kernel.org/linux-mm/20260727154001.4102341-1-uqbarz@gmail.com/ Suggested-by: David Hildenbrand (Arm) Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hannes Reinecke Cc: Hugh Dickins Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Nico Pache Cc: Pankaj Raghav Cc: Ryan Roberts Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 152a00440dc6ef62c6e4cf9bd881a7e6bb81fda9 Author: Hui Su Date: Wed Aug 12 01:39:03 2026 +0800 tracing: Fix NULL pointer dereference in module event cache removal commit b69859204d4db3acd86c1c2dadcef0d77b451933 upstream. A module-only event filter such as ":mod:foo" is cached with a NULL event_mod->match when foo has not been loaded. If a later write tries to remove a specific match from the same module, remove_cache_mod() passes the NULL cached match to strcmp(), causing a NULL pointer dereference. The issue can be reproduced from userspace: echo ':mod:trace_events_kunit_missing' > /sys/kernel/tracing/set_event echo '!foo_bar:mod:trace_events_kunit_missing' >> /sys/kernel/tracing/set_event The second write must be a concatenation (">>") to not include O_TRUNC as that would cause ftrace_clear_events() to clear the cached modules lines. The crash was reproduced on x86_64 QEMU while KUnit workers contended on the event tracing path: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:strcmp+0x10/0x30 Call Trace: __ftrace_set_clr_event_nolock+0x373/0x4a0 ftrace_set_clr_event+0xf0/0x180 ftrace_event_write+0xdf/0x110 vfs_write+0xf6/0x440 ksys_write+0x68/0xe0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Check event_mod->match before comparing it, consistent with the existing NULL checks for the cached system and event fields. The mismatched removal continues to return -EINVAL; a broad cached module filter is removed with "!:mod:". Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260811173902.1927376-2-sh_def@163.com Fixes: b355247df104 ("tracing: Cache \":mod:\" events for modules not loaded yet") Reported-by: syzbot+4d3143c8e28f6266c636@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a7a6b7f.9c11d2ce.289b96.00f8.GAE@google.com/ Signed-off-by: Hui Su Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 62978cf6347972c04130e4e841ba404504d92b32 Author: Vincent Donnefort Date: Thu Aug 6 22:13:02 2026 +0100 ring-buffer: Prevent subbuf order change when resizing is disabled commit bf98d7b0d5a99991e47e66cee4eb1d3fa514be97 upstream. Because ring_buffer_subbuf_order_set() frees buffer pages, we can't allow it when resizing is disabled. A non-consuming reader is at risk of use-after-free (rb_advance_iter()). Return -EBUSY on resize_disabled, matching ring_buffer_resize() behaviour. Cc: stable@vger.kernel.org Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Link: https://patch.msgid.link/20260806211306.3704194-3-vdonnefort@google.com Reported-by: syzbot+e0cc44465d6bae735679@syzkaller.appspotmail.com Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit bc9db0d879c655d5dfd8add32fd60f13e65d132c Author: Rik van Riel Date: Fri Aug 7 22:19:56 2026 -0400 fbdev: bitblit: bound-check glyph index in bit_cursor() commit e033cbf3975a8465f879ebd5989dc35b04423a4d upstream. bit_cursor() fetches the glyph under the cursor with c = scr_readw(vc_pos); src = vc_font.data + ((c & charmask) * w * height); where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count. Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without checking charcount. The stored value is later read in bit_cursor() in bitblit.c. When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access. BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr ffff800086c57970 Call Trace: soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365 fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427 hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883 update_region+0x100/0x18c drivers/tty/vt/vt.c:669 vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685 bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph index to vc_font.charcount. Apply the same clamp in bit_cursor() after extracting the attribute and masking, before indexing fontdata. The fix completes the bounds checking started in commit 18c4ef4e765a ("fbdev: bitblit: bound-check glyph index in bit_putcs*"), which missed the cursor path. This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under console_lock in con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcs_write() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bit_putcs uses. Reported-by: syzbot+61b1db46218109869c14@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=61b1db46218109869c14 Link: https://lore.kernel.org/all/6a75205c.01d0871a.3a0d52.0032.GAE@google.com/ Fixes: 18c4ef4e765a ("fbdev: bitblit: bound-check glyph index in bit_putcs*") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit ed49684e69f846bf50b5050651ccdb87cfd152c0 Author: Michael Wu Date: Mon Aug 10 14:32:30 2026 +0800 tracing: Fix race between update_event_fields and, event_define_fields commit c3730b8373bb5059d735509b9e6a00d7eb337d7c upstream. The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem. Cc: stable@vger.kernel.org Fixes: b3bc8547d3be ("tracing: Have TRACE_DEFINE_ENUM affect trace event types as well") Link: https://patch.msgid.link/2e5730d2-c631-da41-3a3a-ae35bb4895f3@allwinnertech.com Signed-off-by: Michael Wu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a979a642402d0b1f856c7a729b4cb2d92de4cf2f Author: Aditya Chillara Date: Fri Aug 7 18:11:52 2026 +0530 perf/core: Fix group leader use-after-free after sibling detach commit 42c5ca1f0a288a52878bd72a5595b08261057438 upstream. perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change. Fixes: 8a49542c0554 ("perf_events: Fix races in group composition") Assisted-by: PatchWise:gpt-5.5 Signed-off-by: Aditya Chillara Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260807-fix-group-leader-uaf-v3-1-b0c2310c9a0d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 5884851a096d8afcdf91f0e542bac193035183a6 Author: Maíra Canal Date: Tue Jul 28 23:09:22 2026 -0300 drm/v3d: Serialize the scheduler timeout handlers commit 4da94744707b27a3ae1197bdd7127da4505dc5b1 upstream. V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit: [ 327.302739] ------------[ cut here ]------------ [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] Call trace: [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [ 327.302997] process_scheduled_works+0x180/0x3d0 [ 327.303010] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ end trace 0000000000000000 ]--- From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze. The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally. Cc: stable@vger.kernel.org # 6.15 Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260728-v3d-order-global-reset-v1-1-e47be838158d@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 7779249561d14b8a17c0c83783225794e24a587d Author: Baul Lee Date: Tue Aug 4 21:36:25 2026 +0900 ALSA: us144mkii: re-anchor capture URBs on resubmission commit 2615f0fb90df8cf5a96133ca4be74294ed288604 upstream. capture_urb_complete() resubmits each capture URB without anchoring it: usb_get_urb(urb); ret = usb_submit_urb(urb, GFP_ATOMIC); Anchoring is a property of a submission, not of the URB. The giveback path calls usb_unanchor_urb() before urb->complete(), so an URB resubmitted from its own completion handler is off the anchor. The capture URBs are anchored once, at stream start, so from the first completion onward tascam->capture_anchor is empty. tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor) to reap the capture URBs before anything is freed. With the anchor empty those calls return immediately and the URBs stay queued on the host controller. tascam_free_urbs() then returns the capture transfer buffers with usb_free_coherent(), and snd_card_free() releases the snd_card allocation that embeds tascam (card->private_data). The controller completes the queued URBs afterwards, writing device-supplied data into the freed transfer buffer, and capture_urb_complete() dereferences the freed driver object. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in dummy_timer Write of size 512 at addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 64: usb_alloc_coherent tascam_alloc_urbs tascam_probe Freed by task 170: usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface BUG: KASAN: slab-use-after-free in capture_urb_complete Read of size 4 at addr ffff0000170ee878 Freed by task 170: release_card_device snd_card_free tascam_disconnect Restore the usb_anchor_urb() between the reference count bump and the resubmission. That also makes the handler's usb_unanchor_urb() failure arm meaningful again and restores usb_kill_anchored_urbs() as a barrier on the disconnect, suspend and stop-work paths. The anchoring was removed on the premise that the URB is already anchored from the initial submission, which does not hold once the first giveback has run. Discovered by XBOW, triaged by Baul Lee Fixes: 5cff1529a2f9 ("ALSA: us144mkii: capture_urb_complete: redundant usb_anchor_urb corrupts anchor list on each resubmission") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260804123625.91769-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a6b79dff1cc1c29fe915a3be972ae201a0165185 Author: Xu Rao Date: Fri Jul 31 11:35:54 2026 +0800 ALSA: hda/tas2781: fix ACPI reference handling commit 8bec01c80e798eca1ae7863cf29bc6befd759db7 upstream. tas2781_read_acpi() gets a reference to the matching ACPI device and then looks up its first physical device node. After taking a reference to the physical device, it immediately drops the ACPI device reference. However, every later failure jumps to an error path that drops the ACPI device reference a second time. This unbalances the reference count and may prematurely release the ACPI device. In addition, acpi_get_first_physical_node() may return NULL. Without a check, the driver passes the NULL physical device to the property helper calls and may dereference it. Return -ENODEV when no physical device is associated with the ACPI node, and remove the duplicate acpi_dev_put() from the common error path. Fixes: bb5f86ea50ff ("ALSA: hda/tas2781: Add tas2781 hda SPI driver") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/97EA8F29DA0D9AF7+20260731033554.949564-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bb30e35c36ed00f24fa39aded811f64230a913b0 Author: Baul Lee Date: Tue Aug 4 21:36:11 2026 +0900 ALSA: FCP: fix OOB write in fcp_meter_ctl_get() commit 620f1e52a46f604635efd0fb78138afd6a513b5d upstream. fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver's own limit of 255 if (map.map_size < 1 || map.map_size > 255 || map.meter_slots < 1 || map.meter_slots > 255) return -EINVAL; and passes it to fcp_add_new_ctl() as the control's channel count, where it is stored as elem->channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: for (i = 0; i < elem->channels; i++) { int idx = private->meter_level_map[i]; int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]); ucontrol->value.integer.value[i] = value; } snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation. At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this. snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a compile-time true. __snd_ctl_add_replace() validates kcontrol->count and never inspects elem->channels. Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0. KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read: BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185 __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl Allocated by task 185: memdup_user snd_ctl_ioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8) Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds. Discovered by XBOW, triaged by Baul Lee Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260804123611.91715-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f75d6f61f0d9c5c1ea725104014e10d26d1e3a00 Author: Baul Lee Date: Wed Aug 5 10:34:45 2026 +0900 ALSA: usx2y: bound the hwdep mmap fault offset commit 2ca1eea3cd17930daffe9e429a7c89232036ec24 upstream. snd_us428ctls_vm_fault() turns the faulting page offset into a kernel address with no bound of any kind: offset = vmf->pgoff << PAGE_SHIFT; vaddr = (char *)(...)->us428ctls_sharedmem + offset; page = virt_to_page(vaddr); get_page(page); vmf->page = page; return 0; snd_us428ctls_mmap() checks only the length of the mapping, never the offset, and us428ctls_sharedmem is a single page from alloc_pages_exact(). For a character device file_mmap_size_max() returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page offset above zero resolves to a struct page outside the object, and the handler installs it into the caller's address space read-write; the vma is not marked read-only. The caller picks the page frame with a single mmap() argument and gets read-write access to a page of kernel memory it does not own; an offset that lands in an unpopulated vmemmap region oopses instead. A process that can open the hwdep node of an attached US-X2Y reaches this after loading the FPGA image through the same node; no capability check is involved. On 7.2.0-rc5 (arm64), mmap() with a large offset: Unable to handle kernel paging request at virtual address fffffdffc45d5ac8 pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] Call trace: snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] __do_fault __handle_mm_fault handle_mm_fault el0_da Reject any offset outside the shared region. The pcm hwdep handler in usx2yhwdeppcm.c computes its address the same way and needs the same bound. Discovered by XBOW, triaged by Baul Lee Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013445.38283-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d217d723c5e43881b952cdb978477f7f2dc0b6d7 Author: Takashi Iwai Date: Sat Aug 8 17:20:06 2026 +0200 ALSA: usb: Fix UAF at delayed release of MIDI2 EPs commit f8a80cfb68613fb7e6452b66447dbc63f435d140 upstream. The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases. Fixes: 4a05b2d1b464 ("ALSA: usb-audio: fix use-after-free in ump_to_endpoint()") Reported-by: syzbot+565b1138cfbe549d4422@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=565b1138cfbe549d4422 Cc: Link: https://patch.msgid.link/20260808152009.1947835-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 976da5475472e499ffbd97c0ec63afb402a3a57f Author: SJ Park Date: Tue Jul 28 07:04:03 2026 -0700 mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD} commit 1ec0e6b6f7321feb769f50d2f094a0aa6c2eda63 upstream. Callers of migrate_pages() should adjust NR_MIGRATED_{ANON,FILE} for isolations and putback of the folios. That for migration succeeded folios is done by migrate_pages(), in migrate_folio_done(). That for MR_DEMOTION reason is an exception though. DAMOS_MIGRATE_{HOT,COLD} call migrate_pages() but mistakenly not doing the stat adjustment. As a result, use of DAMOS_MIGRATE_{HOT,COLD} could corrupt the stat. It could confuse too_many_isolated(), make compaction and reclaim to behave in unexpected ways. The stat corruption can be reproduced and confirmed using DAMON user-space tool [1] on NUMA systems, like below. $ numactl --hardware available: 2 nodes (0-1) [...] $ sudo ./damo start --damos_action migrate_hot 1 $ sudo cat /proc/sys/vm/stat_refresh $ sudo dmesg [...] [ 80.215554] vmstat_refresh: nr_isolated_anon -5578 [ 80.216842] vmstat_refresh: nr_isolated_file -34400 This issue was discovered [2] by Sashiko. Link: https://lore.kernel.org/20260728140404.94476-1-sj@kernel.org Link: https://github.com/damonitor/damo [1] Link: https://lore.kernel.org/20260726164356.87940-1-sj@kernel.org [2] Fixes: b51820ebea65 ("mm/damon/paddr: introduce DAMOS_MIGRATE_COLD action for demotion") Signed-off-by: SJ Park Cc: Honggyu Kim Cc: Hyeongtak Ji Cc: # 6.11.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e16b8d640ec99b28bc827560edcf9706e610c3aa Author: SJ Park Date: Mon Aug 3 06:40:32 2026 -0700 samples/damon/mtier: error out for zero quota goal target values commit a16fd3ad9d89b05475864da97327870464611736 upstream. Patch series "mm/damon: avoid division by zero from damos_quota_score()". DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division by zero in damos_quota_score(). Avoid it by adding parameters validation checks. This patch (of 2): damos_quota_score() can trigger division by zero if the target_value is zero. DAMON_SAMPLE_MTIER lets users set the target_value via node0_mem_{used,free}_bp parameters. It doesn't guard zero value case, though. As a result, users can trigger division by zero. Fix the issue by returning an error when the user tries to start DAMON with zero node0_mem_{used,free}_bp parameter values. DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite bad. Also the zero node0_mem_free_bp parameter might look like a reasonable setup to some users. Hence, the issue might really happen in the real world. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_sample_mtier/parameters # echo 4096 > node0_start_addr # echo 8192 > node0_end_addr # echo 8192 > node1_start_addr # echo 81920 > node1_end_addr # echo 0 > node0_mem_free_bp # echo Y > enabled # dmesg -w [...] [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI [...] [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480 [...] This issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260803134034.15217-1-sj@kernel.org Link: https://lore.kernel.org/20260803134034.15217-2-sj@kernel.org Link: https://lore.kernel.org/20260801202657.117135-1-sj@kernel.org [1] Fixes: c5e67d40a102 ("samples/damon/mtier: add parameters for node0 memory usage") Signed-off-by: SJ Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 460181e4bb47a57776c64f0832c2096de8878cb3 Author: liyouhong Date: Sun Jul 26 09:48:15 2026 +0800 mm/damon/ops-common: putback folios on invalid migrate nid commit 5deb65c34e682e7c5f5df417a70e223e8fcc5f5a upstream. damon_pa_migrate() and damos_va_migrate() isolate folios into a local list and then call damon_migrate_pages(). When target_nid is invalid (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages() returns early without putting the folios back to the LRU. Callers then discard the list head while those folios remain isolated with an extra reference taken by folio_isolate_lru(). The pages stay off the LRU for as long as the mapping exists (anon active+inactive counts drop while RSS does not), and the leftover references can pin the pages after the mapping is gone. Put the folios back on the invalid-nid path so ignored migration requests still return them to the LRU. Link: https://lore.kernel.org/20260726014815.1280757-1-dayou5941@163.com Fixes: 7e6c3130690a ("mm/damon/ops-common: ignore migration request to invalid nodes") Assisted-by: Cursor:grok-4.5 Reviewed-by: SJ Park Signed-off-by: liyouhong Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6dd7a06894d6d3dc84319bd0b7d1a7c27df9d902 Author: Hui Su Date: Fri Aug 7 23:41:46 2026 +0800 ring-buffer: Fix crash passing ERR_PTR to kthread_stop() commit 91542863abade2fd4f2b361991f5386ad9d19c8c upstream. In test_ringbuffer()'s out_free cleanup loop, the check `!rb_threads[cpu]` only catches NULL entries and misses entries that hold an ERR_PTR. rb_threads[] is static, so unassigned slots are NULL. But when kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or -EINTR) in rb_threads[cpu] before the creation loop jumps to out_free. That entry is non-NULL, so the old `!ptr` check does not break, and the cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop() then dereferences the bogus pointer, crashing the kernel during the late_initcall self-test. crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 Kernel panic - not syncing: Fatal exception Cc: stable@vger.kernel.org Fixes: 64ed3a049e3e ("ring-buffer: make use of the helper function kthread_run_on_cpu()") Link: https://patch.msgid.link/20260807154145.2846521-2-sh_def@163.com Signed-off-by: Hui Su Reviewed-by: Vincent Donnefort Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 688c71bed6852e61126c4510c6039d9e8a5453dd Author: Eddie Lin Date: Fri Jul 24 23:33:41 2026 +0100 misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free commit 2fae94ee14f7fea11d3f95e10383a87c01d21518 upstream. The 'ctx_idr' is initialized but never destroyed when the channel context is freed, leading to a memory leak. Add idr_destroy() to properly clean up the IDR resources. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Eddie Lin Reviewed-by: Ekansh Gupta Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-6-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit af6345159abcbaa550518f31990d2a9558c2d369 Author: Junrui Luo Date: Fri Jul 24 23:33:39 2026 +0100 misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke commit b85a0e91d7d6cd06a53c881a46f749cfcef416a2 upstream. When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor. Fixes: 76e8e4ace1ed ("misc: fastrpc: Safekeep mmaps on interrupted invoke") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9bf22a7d950cec2d1efeca7f16bb20fcca84c36a Author: Ekansh Gupta Date: Fri Jul 24 23:33:38 2026 +0100 misc: fastrpc: Remove buffer from list prior to unmap operation commit 6102ceb4eab845743ee57acd3863fbd06e93c927 upstream. fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list. Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Ekansh Gupta Signed-off-by: Jianping Li Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c5a03c2cadd2f07d585f4bef8b860721fb01343a Author: Anandu Krishnan E Date: Fri Jul 24 23:33:40 2026 +0100 misc: fastrpc: fix channel ctx ref leak when session alloc fails commit 310f7868399668c6d99d88acc9c4cf3462e69d5b upstream. fastrpc_channel_ctx_get() is called in fastrpc_device_open() before fastrpc_session_alloc(). If session alloc fails, the error path returns -EBUSY without calling fastrpc_channel_ctx_put(), leaking the reference. Fix by adding the missing put. Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit cd02b9386315938ec99ef141a3437c2e67f04d0c Author: Ekansh Gupta Date: Fri Jul 24 23:33:37 2026 +0100 misc: fastrpc: Fix initial memory allocation for Audio PD memory pool commit ab99eaafb0c4b412cfeb895a8cf091626e2bbd86 upstream. The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Ekansh Gupta Signed-off-by: Jianping Li Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 8b3e4ed9c35d3d3b64fcc23f4a1f22b37c1865b1 Author: Mariano Baragiola Date: Mon Jul 27 13:08:59 2026 -0300 staging: rtl8723bs: validate monitor transmit frame lengths commit 6829665d050983907b560173e49dcc6c11cb2730 upstream. rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and then reads the 802.11 frame control field without checking that a base 802.11 header remains. The data path also pulls the calculated 802.11, QoS and SNAP header span before confirming that the skb contains it. A truncated frame can therefore cause out-of-bounds reads or leave insufficient data for the Ethernet address writes. Reject frames that do not contain the base 802.11 header and data frames that do not contain their complete calculated header span. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Mariano Baragiola Link: https://patch.msgid.link/20260727160859.1917096-1-mbaragiola@linux.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a28a4b0592e4a37ea471bc0d308513a93133ce7e Author: Panagiotis Petrakopoulos Date: Mon Jul 20 11:24:09 2026 +0300 staging: rtl8723bs: fix missing shared-key auth challenge length check commit 2c56ef658ac8c6bca36bc5574715e8f717207c6c upstream. The WEP shared-key authentication handler uses the challenge-text element's attacker-controlled length without checking it against the fixed 128-byte chg_txt buffer. In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used to perform memcpy() into the 128-byte pmlmeinfo->chg_txt, so a malicious AP sending a malformed WLAN_EID_CHALLENGE element can overflow/underfill chg_txt by up to 127 bytes. It is reachable over the air, before association, during shared-key authentication. In the case of an overflow, the driver can write out of bounds. In the case of an underfill, the driver can echo stale buffer memory. The challenge text is defined to be exactly 128 octets, which is already provided as the WLAN_AUTH_CHALLENGE_LEN define; require the element to be exactly that length before use. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Panagiotis Petrakopoulos Link: https://patch.msgid.link/20260720082409.168379-1-npetrakopoulos2003@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e5b7610008f4e6a80c8b071aa77ddbd5e17ea472 Author: Muhammad Bilal Date: Sun Jul 19 09:15:09 2026 +0500 staging: rtl8723bs: fix OOB read in WMM_param_handler() commit ae21407350151bddfd4fea7aa39bd0643c0ca9d3 upstream. WMM_param_handler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE. The handler reads sizeof(struct WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a 4-byte OUI, before calling the handler. A vendor-specific IE carrying the WMM OUI but a length between 6 and 23, placed in an association response or in the IE blob handed to join_cmd_hdl(), passes the OUI check and then makes the memcmp() and memcpy() at pIE->data + 6 read past the end of the element. OnAssocRsp() parses a frame received from the AP, so this is reachable from a remote peer. The remaining caller in rtw_wlan_util.c already guards the handler with "pIE->length == WLAN_WMM_LEN". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HT_caps_handler(), HT_info_handler(), ERP_IE_handler()) likewise bound their accesses by pIE->length. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260719041509.97894-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e167a38a8a8f50f137721fef1a1fbba0f4588b5d Author: Muhammad Bilal Date: Sun Jul 19 08:06:31 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie() commit 1c3e23e78862493e8cf1adad02b10ffcb8b9921c upstream. rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific information element without checking that the element is long enough, causing an out-of-bounds read for a short trailing IE. The function locates a vendor-specific IE (EID 221) with rtw_get_ie() and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte version word at pbuf + 6. Those accesses require the IE body to be at least 6 bytes, but rtw_get_ie() only guarantees that the element fits within the buffer; it does not enforce a minimum body length. A vendor-specific IE whose length byte is 0 to 5, placed at the end of the buffer, therefore makes these reads run past the end of the IE and past the end of the buffer itself. The buffer holds information elements taken from received management frames and from the IE blob passed to rtw_cfg80211_set_wpa_ie(), which is kmemdup'd to its exact length, so the read can run off the end of the allocation. The sibling helpers rtw_get_sec_ie(), rtw_get_wapi_ie() and rtw_get_wps_ie() in this file already reject too-short vendor-specific IEs before their OUI memcmp(); rtw_get_wpa_ie() was never brought in line with them, and needs a minimum of 6 rather than 4 bytes because of the version word. Add the missing length check. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260719030631.88254-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5974cb66681eac367107b05924744d7e3b49d41c Author: Fan Wu Date: Fri Jul 31 08:59:15 2026 +0000 serial: amba-pl011: synchronize DMA teardown commit 440915499231e9db1c361aa45bb702e8fd3b4a32 upstream. dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers. Fixes: ead76f329f77 ("ARM: 6763/1: pl011: add optional RX DMA to PL011 v2") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260731085915.326775-4-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 759ead98a39fb625be302f9aa66290985dcaa325 Author: Fan Wu Date: Fri Jul 31 08:59:14 2026 +0000 serial: amba-pl011: cancel RS485 hrtimers after freeing IRQ commit 36672c8d7d14e9c43287528455d2c97b526ea6ad upstream. The RS485 trigger hrtimers are embedded in the devm-managed port and can fire after it is freed. The IRQ handler can arm a timer, so free the IRQ first and then cancel both timers. Complete the RS485 stop without arming a timer, and cancel the timers in remove() for the suspend-then-unbind path, where shutdown is not called. This issue was found by an in-house static analysis tool. Fixes: 2c1fd53af21b ("serial: amba-pl011: Fix RTS handling in RS485 mode") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260731085915.326775-3-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2a0ee25f75cdb524526d2fd46be97c00da647970 Author: Fan Wu Date: Fri Jul 31 08:59:13 2026 +0000 serial: amba-pl011: fix indefinite RS485 post-send delay commit dcb2f7576ce460eb4f6b9048b7c266c8da5848a8 upstream. The RS485 stop hrtimer is used both to drain the transmitter and to wait out delay_rts_after_send. The callback cannot tell the two apart, so it restarts the post-send delay on every expiry and the timer never stops. Add a WAIT_AFTER_SEND_DELAY state so its expiry ends the stop sequence instead of restarting the delay. Fixes: 2c1fd53af21b ("serial: amba-pl011: Fix RTS handling in RS485 mode") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260731085915.326775-2-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3ce24bc4d115336218e59b7e286fd3a79f4fc4c6 Author: Ryan Wilbur Date: Thu Jul 30 16:39:20 2026 -0300 serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx commit 1423415471274abda87024967d7fe2206ceee0ea upstream. The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear. This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271. Cc: stable Assisted-by: Claude:Opus4.8 Signed-off-by: Ryan Wilbur Link: https://patch.msgid.link/20260730193920.28954-1-rwilbur633@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit ae05d9e50b6b9f246c110b3bdc03676145c2d0d4 Author: Cunhao Lu <1579567540@qq.com> Date: Mon Jul 27 14:25:22 2026 +0800 serial: 8250_dma: Clear stale RX state on shutdown commit e2fe6a0efecbef00e3ecc2db64dd5afa8c212b41 upstream. serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 ("serial: 8250_dw: Ensure BUSY is deasserted") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API. Fixes: 0fcb7901f9d6 ("tty: serial: 8250_dma: keep own book keeping about RX transfers") Cc: stable Signed-off-by: Cunhao Lu <1579567540@qq.com> Link: https://patch.msgid.link/tencent_9EE2945F4C933B4D810C73C2D7485E000F06@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1c31e2377f4c1bb110ca7f6e597b2253a7440c37 Author: Jan Sebastian Götte Date: Wed Jul 29 19:41:05 2026 +0200 serial: qcom-geni: fix TX DMA buffer flush commit e3c04834ae1ab5e9cfbe8ac54ec734aa4774249d upstream. When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames. The DMA-mode uart_ops does not provide a flush_buffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears tx_remaining and tx_queued. The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive. The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1. Assisted-by: Claude:claude-5-opus Codex:gpt-5 Signed-off-by: Jan Sebastian Götte Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable Reviewed-by: Praveen Talari Link: https://patch.msgid.link/20260729174105.21838-2-git@jaseg.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit dd6946a70ddbd07269cbf7565193e8dd539abc43 Author: Alice Ryhl Date: Mon Jul 27 12:28:59 2026 +0000 rust_binder: do not query current thread for all ioctls commit dd7aea9ee2091cfae3a5e376af87aa106d7735cd upstream. The get_current_thread() method is currently called for every ioctl to ensure that a Thread struct exists for the thread calling into the driver. However, not all ioctls require a Thread object, so this means we are unnecessarily creating these objects in cases where we don't need to. If said thread does not invoke BINDER_THREAD_EXIT on exit, Binder's Thread struct stays around until the fd is closed. For long-lived processes the Thread object is effectively leaked. Furthermore, when the BINDER_GET_NODE_DEBUG_INFO ioctl is invoked by libmemunreachable to ensure that objects reachable only through the Binder driver are not considered leaked, this is done from a fork of the process owning the fd, which means that it fails the group_leader check inside get_current_thread(). This results in EINVAL errors for this ioctl, causing libmemunreachable to report a false positive memory leak. Thus, do not invoke get_current_thread() for ioctls that do not require it. Signed-off-by: Alice Ryhl Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260727-binder-cur-thread-v1-1-8edf2b64e235@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9dbe1d0111893cba1fe8106401652c26f882673f Author: Mathieu Dubois-Briand Date: Fri Jul 24 23:34:04 2026 +0100 nvmem: layouts: Add fixed-layout driver commit b5be879519291f139fa7b365fd0dbc84710e4919 upstream. Current implementation isn't working well when device tree nodes have a phandle on a fixed-layout nvmem node. As the fixed layout is handled in nvmem core, no driver is ever associated with the layout, and the device consumer driver probe is deferred indefinitely. Remove the specific handling of fixed-layout and add a layout driver. This makes the fixed-layout similar to all other layouts, fixing the whole issue. Fixes: fc29fd821d9a ("nvmem: core: Rework layouts to become regular devices") Cc: stable@vger.kernel.org Reviewed-by: Miquel Raynal Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223404.629248-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit da59844f561d12de39dcd71b6b2381a9f976406b Author: Aelin Reidel Date: Fri Jul 24 23:34:03 2026 +0100 nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFI commit ff10b6db0ab75b132aed69ab144ac04f63ef9bdb upstream. The Apple SPMI NVMEM driver previously cast regmap_bulk_read/write to void * when assigning them to nvmem_config's reg_read/reg_write function pointers. This cast breaks the expected function signature of nvmem_reg_read_t and nvmem_reg_write_t. With CFI enabled, indirect calls through these pointers fail: CFI failure at nvmem_reg_write+0x194/0x1e4 (target: regmap_bulk_write+0x0/0x2c8; expected type: 0x83a189c3) ... Call trace: nvmem_reg_write+0x194/0x1e4 (P) __nvmem_cell_entry_write+0x298/0x2e8 nvmem_cell_write+0x24/0x34 macsmc_reboot_probe+0x1dc/0x454 [macsmc_reboot] ... Introduce thin wrapper functions with the correct nvmem function pointer types to satisfy the CFI checks. Fixes: fe91c24a551c ("nvmem: Add apple-spmi-nvmem driver") Signed-off-by: Aelin Reidel Reported-by: Clayton Craft Tested-by: Clayton Craft Reviewed-by: Sven Peter Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223404.629248-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 104c2e8b8e38bfb10e8e2e384dd8a7a86a643f35 Author: Alexander Usyskin Date: Sun Jul 19 12:57:55 2026 +0300 mei: pull kvfree out of spinlock commit b0495bb58af06a7de4628c72d500e3d5e180d808 upstream. The read buffer allocation was changed from kmalloc() to kvmalloc(). This buffer is part of mei_cl_cb structure that can be queued in rd_complete queue protected by spinlock. Releasing the structure leads to errors like below when freeing buffer that allocated non-contiguous: BUG: sleeping function called from invalid context at mm/vmalloc.c:3448 Separate mei_cl_cb structure dequeue and release to perform only dequeue under spinlock and push release out of spinlock. Cc: stable Fixes: 4adf613e01bf ("mei: use kvmalloc for read buffer") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16359 Reviewed-by: Menachem Adin Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260719-kvfree_out_of_spinlock-v1-1-e07d6333bea7@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 63996ffc594d128ccec8fc0983f91effd2d3adc4 Author: Chengfeng Ye Date: Sat Aug 8 02:17:10 2026 +0800 ipv4: fix use-after-free in fib_nhc_update_mtu() commit bc5bde9ce3cc36502839dfe98e068f7303a50982 upstream. fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) access fnhe after grace period KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop. Fixes: af7d6cce5369 ("net: ipv4: update fnhe_pmtu when first hop's MTU changes") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel Signed-off-by: Chengfeng Ye Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260807181710.1178747-1-nicoyip.dev@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a59edda6eda1252340354322d8ab318b2e9052fb Author: Zihan Xi Date: Thu Jul 30 12:59:26 2026 +0000 ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops commit 4ff9548d84945d2cbf9e4c207288063a200ea397 upstream. fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present. Fixes: d15662682db2 ("ipv4: Allow ipv6 gateway with ipv4 routes") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/6f53fa797fcaeb26966432ed7ae9bb87c4961f37.1785411220.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 94166072975aa6c8d967b59061454c19353185d0 Author: Michal Luczaj Date: Tue Jul 7 06:23:58 2026 +0200 selftests/bpf: Adapt sockmap update error handling [ Upstream commit 30581eda4a07ff15db623612cac578e81869e96f ] Update sockmap_listen to accommodate the recent change in sockmap that rejects unbound UDP sockets. TCP: Reject unbound and bound (unless established or listening). UDP: Accept only bound sockets. While at it, migrate to ASSERT_* and enforce reverse xmas tree. Signed-off-by: Michal Luczaj Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20260707-sockmap-lookup-udp-leak-v4-3-f878346f27ab@rbox.co Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit edee58a9c460a6d8b73ca90235aad80612e9a6eb Author: Michal Luczaj Date: Tue Jul 7 06:23:56 2026 +0200 selftests/bpf: Ensure UDP sockets are bound [ Upstream commit fe3ff273767ef22fe8a7cb3816f264927c190e50 ] Update sockmap_basic tests to bind sockets before they are used. This accommodates the recent change in sockmap that rejects unbound UDP sockets. Signed-off-by: Michal Luczaj Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20260707-sockmap-lookup-udp-leak-v4-1-f878346f27ab@rbox.co Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit dc0c462fa838c507d83e89d553d058e0a3389b6c Author: Nils Helmig Date: Sat May 30 14:39:34 2026 +0200 Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV [ Upstream commit bc597f0cc44f0b173c50ee986a047219cd559ee9 ] Add the vendor/product ID (0x37ad, 0x0600) to usb_device_id table for Realtek 8761BUV. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=37ad ProdID=0600 Rev= 2.00 S: Manufacturer= S: Product=TP-Link Bluetooth USB Adapter S: SerialNumber=ACA7F14FD2A5 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 E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Nils Helmig Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 373d425f7638ac9a38d9b35391633830f2cc3abf Author: Alexej Sidorenko Date: Wed Apr 29 17:13:43 2026 +0200 Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan [ Upstream commit 5ead2063611ae56809b1b113ac44cef9547c81d7 ] RTL8761B and RTL8761BU devices report HCI version 5.1 but do not support the LE Extended Scan commands. This causes repeated failures with Opcode 0x2042 (LE Set Extended Scan Parameters) returning -EBUSY when BlueZ attempts extended scanning while a connection is active. Set HCI_QUIRK_BROKEN_EXT_SCAN for CHIP_ID_8761B to make BlueZ fall back to legacy LE scan commands which the firmware supports correctly. Tested with RTL8761BU (USB ID 0bda:a728) where the issue manifested as continuous 'Opcode 0x2042 failed: -16' errors in dmesg whenever a BLE connection was active. Signed-off-by: Alexej Sidorenko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8545f4ef9eae62917d033a9348e7631f3be2ffcf Author: Florian Westphal Date: Thu Dec 11 12:55:19 2025 +0100 netfilter: nf_tables: avoid softlockup warnings in nft_chain_validate [ Upstream commit 7e7a817f2dfd79098a706ee5581ea9518b2de878 ] This reverts commit 314c82841602 ("netfilter: nf_tables: can't schedule in nft_chain_validate"): Since commit a60a5abe19d6 ("netfilter: nf_tables: allow iter callbacks to sleep") the iterator callback is invoked without rcu read lock held, so this cond_resched() is now valid. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 7b8c53263f8878bdd12c87e147ac6feca5c05211 Author: Keno Fischer Date: Fri Aug 14 14:43:28 2026 +0200 futex: Prevent robust futex exit race some more commit 6d4514ca9cdf61fec4ec634cf50386f6f7e69748 upstream. A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ] Fixes: ca16d5bee598 ("futex: Prevent robust futex exit race") Signed-off-by: Keno Fischer Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Assisted-by: ClaudeCode:claude-fable-5 tla+ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260730194705.38981-1-keno@juliacomputing.com Signed-off-by: Sasha Levin commit cf8a9672fc25cf434eb063c181b83c576e70e7b4 Author: Jose Fernandez (Anthropic) Date: Thu Aug 13 00:05:26 2026 +0000 iommu/vt-d: Gather the unmapped range before freeing its page tables In the 6.12 and 6.18 stable trees, when an unmapped range covers a whole page table, intel_iommu_unmap() can free that table before the range has been invalidated. The freed table goes on gather->freelist before the range is added to the gather. If iommu_iotlb_gather_add_page() syncs before adding it, that sync flushes only the earlier ranges but frees the whole freelist, that table included. The range itself is flushed later with an empty freelist, which means the flush is sent with the invalidation hint set and the IOMMU may keep its paging-structure cache entry for the freed table. DMA to the next mapping at that IOVA is then translated through whatever the freed page holds by then, which is usually a silent wrong translation and sometimes a DMAR fault. Under a userspace driver that maps and unmaps DMA buffers through VFIO type1 continuously, this shows up as wrong data in device reads and writes. An occasional DMAR fault on a mapped IOVA is the only thing in the logs. With an Intel DSA engine assigned through vfio-pci, remapping a 16 MiB buffer at a fixed IOVA and reading it through the device returned data from the wrong pages in 280 of 400 iterations. With a fresh IOVA per iteration it never did. Add the range to the gather first and splice the freed tables into gather->freelist afterwards, so that they are only freed by a sync that also invalidates their range. Mainline removed this code in v6.19 with commit d373449d8e97 ("iommu/vt-d: Use the generic iommu page table") and is not affected. Fixes: 2a2b8eaa5b25 ("iommu: Handle freelists when using deferred flushing in iommu drivers") Cc: stable@vger.kernel.org # 6.12.y, 6.18.y Reported-by: Mohammed Almaroof Reviewed-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Jose Fernandez (Anthropic) Signed-off-by: Sasha Levin commit 643b410bdfa4819a53e0ce0acdbc2c80a0553263 Author: Harshal Dev Date: Wed Aug 12 19:27:54 2026 +0530 dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk [ Upstream commit e27264daac7d9ce892a2a5b4a864d6d9a3c9276a ] The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC power-domain and iface clock. Without enabling the iface clock and the associated power-domain the ICE hardware cannot function correctly and leads to unclocked hardware accesses being observed during probe. Extend and fix the DT bindings for inline-crypto engine by allowing description of the iface clock and UFS_PHY_GDSC power-domain. This patch has been adapted from the mentioned upstream commit to drop references to Eliza and Milos Qualcomm platforms which do not exist on the stable tree. Thus, patch now fixes the original commit which introduced the DT binding for Qualcomm inline-crypto engine. Fixes: f6ff91a47ac5 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine") Reviewed-by: Kuldeep Singh Reviewed-by: Krzysztof Kozlowski Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-1-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8d817ef1aa4e9e750eeca7115fef2a74f67b8b38 Author: Matthew Rosato Date: Wed Aug 12 13:37:29 2026 -0700 KVM: s390: pci: Fix aisb calculation [ Upstream commit 0cfe660559e857d7c00ab86c73e4510ce069086f ] The current implementation of aisb calculation will erroneously index via an unsigned long * as well as multiply by 8B for every 64-bits in the offset; only one or the other is required. This throws off aisb calculations once the number of devices exceeds 64, and can result in out-of-bounds access as well as failure to indicate summary bits associated with those devices in guests. Fix this by converting to a physical address before applying the offset, as is already done in arch/s390/pci/pci_irq.c. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle Signed-off-by: Christian Borntraeger [alifm@linux.ibm.com: Resolved merge conflict] Signed-off-by: Farhan Ali Signed-off-by: Sasha Levin commit cf895cd72e4049f9273c437129842728911aae8c Author: Keith Busch Date: Wed Aug 12 11:25:45 2026 +0000 blk-mq: reinsert cached request to the list [ Upstream commit b051bb6bf0a231117036aa607cadf55be8e63910 ] A previous commit removed an optimization out of caution for a scenario that turns out not to be real: all the "queue_exit" goto's are safe to reinsert the request into the cached_rq's plug list as they are either from a non-blocking path, or a successful merge that already holds the queue reference. This optimization is most needed for small sequential workloads that successfully merge into larger requests. Fixes: dc278e9bf2b9 ("blk-mq: pop cached request if it is usable") Suggested-by: Ming Lei Suggested-by: Christoph Hellwig Signed-off-by: Keith Busch Reviewed-by: Chaitanya Kulkarni Link: https://patch.msgid.link/20260526153531.2365935-1-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Simon Liebold Signed-off-by: Sasha Levin commit 97e2d08de282ef76f84ab4ccd00f1acb3f5f999e Author: Keith Busch Date: Wed Aug 12 11:25:44 2026 +0000 blk-mq: pop cached request if it is usable [ Upstream commit dc278e9bf2b9513a763353e6b9cc21e0f532954e ] When submitting a bio to blk-mq, if the task should sleep after peeking a cached request, but before it pops it, the plug flushes and calls blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a use-after-free bug. Fix this by popping the cached request before any possible blocking calls if it is suitable for use. Popping this request first holds a queue reference, so avoid any serialization races with queue freezes and can safely proceed with dispatching that request to the driver. This potentially increases a timing window from when a driver wants to freeze its queue to when requests stop being dispatched. That scenario is off the fast path though, and drivers need to appropriately handle requests during a freeze request anyway. The downside is the popped element needs to be individually freed when we performed a bio plug merge. The cached request would have had to be freed later anyway, but this patch does it inline with building the plug list instead of after flushing it. Fixes: b0077e269f6c1 ("blk-mq: make sure active queue usage is held for bio_integrity_prep()") Fixes: 7b4f36cd22a65 ("block: ensure we hold a queue reference when using queue limits") Signed-off-by: Keith Busch Link: https://patch.msgid.link/20260521190253.242065-1-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Simon Liebold Signed-off-by: Sasha Levin commit 59b07ccca4c0546640e72f91f1e9ff8247272abf Author: Alex Deucher Date: Wed Aug 12 10:49:01 2026 -0400 Revert "drm/amd/display: Fix backlight max_brightness to match exported range" This reverts commit 490ceacd2162de919a142bcb4eff363bb493b1de. This patch is apparently missing a dependency from 7.2 as users have not reported any regressions with 7.2-rc, but there are regressions on 6.18. The regression manifests as inconsistent lower brightness at the top end (e.g., around 98%). Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5562 Signed-off-by: Alex Deucher Cc: Thorsten Leemhuis Cc: Sergio Callegari Cc: Mario Limonciello Signed-off-by: Sasha Levin commit 5912cf1822fbe53ae275c147868740eb384a5d3e Author: Baul Lee Date: Wed Jul 29 22:19:41 2026 +0900 net: bridge: mrp: fix uninitialised bytes on the wire commit 63488dba65ef91373ef616575b32eb0eb21459f4 upstream. br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with sub_tlv = skb_put(skb, sizeof(*sub_tlv)); sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have. Fixes: f7458934b079 ("net: bridge: mrp: Update the Test frames for MRA") Suggested-by: Nikolay Aleksandrov Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260729131941.10254-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 47a119ec8a7e2d5c8c4e86fb1a56c4e696e500fb Author: Chengfeng Ye Date: Thu Jul 30 01:31:00 2026 +0800 netfilter: ebt_nflog: pin the NFLOG backend commit 30825970339c107bacaf7f61af90fcdb1f597ca1 upstream. nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_subsys() kfree(nfnl_log_pernet(net)) ebt_nflog_tg() nf_log_packet() nfulnl_log_packet() instance_lookup_get_rcu() The global ULOG logger is still registered at this point, so CPU 1 dereferences the per-net state after CPU 0 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu Read of size 8 at addr ff110001052e6210 by task poc/92 Call Trace: instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 Allocated by task 90: __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 Freed by task 93: kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] Acquire the ULOG logger module reference when an ebt_nflog rule is validated and release it when the rule is destroyed. Request the NFLOG backend for legacy callers when needed, matching xt_NFLOG. This prevents module teardown until all ebt_nflog rules have stopped using the logger. Fixes: c83fa19603bd ("netfilter: nf_log: don't call synchronize_rcu in nf_log_unset") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a0e76de6a2f2872389290758cf2c93c3fdbae9c7 Author: Philipp David Date: Tue Aug 4 15:22:03 2026 -0700 igc: fix netdev not re-attached after resume if interface is down commit b0ce5fd9fabe7c79463cf4602217d4dfeff5b1fd upstream. __igc_resume() calls netif_device_attach() only inside the netif_running() branch, so an interface that was down during suspend is never re-attached on resume. It then stays in the not-present state that __igc_shutdown() set via netif_device_detach(): ethtool reports ENODEV and every attempt to bring the interface up fails the netif_device_present() check in __dev_open() with -ENODEV, silently, since __igc_resume() returns 0. Only reloading the driver recovers the device. This is easy to hit in practice because NetworkManager brings managed interfaces down before sleep unless Wake-on-LAN is configured, making the adapter unusable after every suspend/resume cycle with WoL disabled. Re-attach the netdev on every successful resume, as igb and e1000e do. Fixes: 6f31d6b643a3 ("igc: Refactor runtime power management flow") Cc: stable@vger.kernel.org Signed-off-by: Philipp David Reviewed-by: Aleksandr Loktionov Reviewed-by: Dima Ruinskiy Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260804222205.1580328-11-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e6cd416a899edc912b428c4ba399bd73f516cb31 Author: Zihan Xi Date: Sun Aug 2 09:23:34 2026 +0000 mac802154: fix netdev use-after-free in beacon worker commit 5f26a690e8efa54315e4922368daf54e0b8f5515 upstream. mac802154_beacon_worker() reads local->beacon_req under RCU and derives the sub-interface from the request, but then drops the RCU read lock and continues to use both sdata and the embedded wpan_dev. mac802154_stop_beacons_locked() cancels only pending beacon work, clears local->beacon_req and frees the request. A beacon worker that is already running can therefore continue after interface teardown and dereference the freed netdev private area. The scan worker already pins the netdev before leaving RCU. Apply the same lifetime rule to the beacon worker: take a netdev reference while the request is still protected by RCU, and release it on all paths that continue after the reference is acquired. Fixes: 3accf4762734 ("mac802154: Handle basic beaconing") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/e9a3909c7a6281967961773ca841e860b8ecf40e.1785596603.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9f904dd3e455750e5d4ec9b2f134835811b85a2f Author: Zhiling Zou Date: Tue Jul 28 01:23:29 2026 +0800 inet: frags: publish queues before arming timer commit 653d7ddf6cba867777a3d14c4f83ace008c5ad13 upstream. inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference. Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Link: https://patch.msgid.link/bf66785e7c0c139d7a1900e2f01faeeab344b960.1784948849.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dbb30dc943a93e083f1e531bfdc6779e57de40d0 Author: Qihang Tang Date: Wed Aug 5 20:57:27 2026 +0800 net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header commit 3b9a324e646d3657a8d9806dfbfe4f3e4066e882 upstream. dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite. This path is only reached for variable length L2 protocols, where len < hard_header_len but len >= min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact. Suggested-by: Willem de Bruijn Fixes: 2793a23aacbd ("net: validate variable length ll headers") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260805125729.19220-2-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 99ae2239069ed4f8cb74dcdc37a8de6ee90c12fc Author: Sergey V. Frolov Date: Tue Aug 4 15:04:48 2026 +0300 net: octeontx2-pf: Fix UB in shift operation commit 7e2d693af0d4c05bddccb3541a0aabd69f4cb244 upstream. In function otx2_get_egress_burst_cfg, when the parameter `burst` is 255 and the max mantissa is 255 (0xFFULL), `burst_exp` is set to `ilog2(255) - 1`, which equals 6. This results in an unsigned wrap-around when calculating `(1ULL << (*burst_exp - 7))`, since `*burst_exp - 7` becomes -1, which makes the shift operand 0xFFFFFFFF. This value is greater than the width of the left operand. According to standard 6.5.7 p.3: "The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." Fix the off-by-one boundary condition. Add a WARN_ON(*burst_exp < 7) before the else branch as an explicit safeguard. This ensures that if max_mantissa ever changes in a way that reintroduces this condition, it will be immediately caught at runtime rather than silently triggering UB. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e638a83f167e ("octeontx2-pf: TC_MATCHALL egress ratelimiting offload") Signed-off-by: Sergey V. Frolov Cc: stable@vger.kernel.org Reviewed-by: Ratheesh Kannoth Reviewed-by: Sunil Goutham Link: https://patch.msgid.link/20260804120446.1955448-1-Sergey.V.Frolov@kaspersky.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a4b14a4df29d36458a943f9b521ddd0f940363cc Author: Zijie Huang Date: Sat Aug 1 21:42:33 2026 +0800 net/sched: reject overly deep qdisc hierarchies commit dedd34b0f2310e28c5f6d4875cfbf4b7ed821c01 upstream. Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Suggested-by: Jamal Hadi Salim Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zijie Huang Signed-off-by: Ren Wei Reviewed-by: Victor Nogueira Link: https://patch.msgid.link/1e9ab39597423fd5d13cfaaf52279b8ee3d9fc3c.1785434373.git.milkory@outlook.com Acked-by: Jamal Hadi Salim Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 23716dd9d8d46a5908536b73dc085e62f2b5c237 Author: Zhiling Zou Date: Mon Aug 3 08:29:36 2026 +0800 net: openvswitch: reallocate update replies for mismatched IDs commit 5d1c224dd914579524a183a514c12b95095d12ce upstream. ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails. Fixes: 74ed7ab9264c ("openvswitch: Add support for unique flow IDs.") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/f7bbd3c30ce81a39156e226b3872d73abed21d2f.1785644623.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5f30f9c302cea1f2ebf97abe574c1826544223d7 Author: Sun Jian Date: Mon Aug 3 22:40:38 2026 -0700 net: fix skb length accounting after generic XDP frag adjustment commit 33f2b2eb33d666ecac68031e0f31424fb70528db upstream. Generic XDP exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, bpf_prog_run_generic_xdp() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. Fixes: e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/al9T9Eto%2FhRIzP5W@boxer/ Reviewed-by: Mohsin Bashir Acked-by: Lorenzo Bianconi Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260804054040.613675-2-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2c7b5eb87b2b288cdbde825f21d2b83b2f5da747 Author: Zihan Xi Date: Wed Jul 29 09:16:53 2026 +0000 packet: synchronize pressure clearing with ring reconfiguration commit 1a35da325cac4d5bcad76a2aa943408a6f1d9000 upstream. packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly. Fixes: 2ccdbaa6d55b ("packet: rollover lock contention avoidance") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi Link: https://patch.msgid.link/f90b5688311fa278d1361ea8c6be0bf25967d591.1785247446.git.zihanx@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 971aa7d99242bbf09513e27b7a243f0b29ff23ae Author: Doruk Tan Ozturk Date: Fri Jul 24 16:40:15 2026 +0200 net/packet: reset the MAC header on the packet-socket transmit path commit c2707480cfbf19c7619acc9c089d17f20869821f upstream. packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c ("macsec: do not read an unset MAC header in macsec_encrypt()"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested. Fixes: 75c65772c3d1 ("net/packet: Ask driver for protocol if not provided by user") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260724144015.63219-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 27e068d1b35dbec10a3cf268887c94407be4badc Author: Qihang Tang Date: Wed Aug 5 20:57:29 2026 +0800 packet: use consistent hard_header_len in TX_RING send path commit 21b5953e7494c16a42e6cd8cf110e18d13ae4a6b upstream. tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260805125729.19220-4-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5bb10753d428aadfc356a2bfe9acea09c82a62ec Author: Qihang Tang Date: Wed Aug 5 20:57:28 2026 +0800 packet: use consistent hard_header_len in non-ring send paths commit 03390aa32e669cc4ecd7d34108e2e1afc13d689d upstream. packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260805125729.19220-3-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 75eec935444db4af2123e0491936f6e273d7ea00 Author: Kyle Zeng Date: Tue Aug 4 06:10:55 2026 +0000 ipvs: clear IPv4 options after rebasing tunnel ICMP errors commit e0ba936287dfe9783426aac27e5fd76fe35b38c9 upstream. ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write. Clear the stale option metadata after resetting the network header. Keep the remaining control block fields, including the ingress interface used by the ICMP response path. Fixes: f2edb9f7706d ("ipvs: implement passive PMTUD for IPIP packets") Cc: stable@vger.kernel.org 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 Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 0f88fe0552bee51cbb650c133edfb754a3189bf6 Author: Julian Anastasov Date: Fri Jul 31 22:27:42 2026 +0800 ipvs: properly update the overload flag on dest edit commit 8f843441c4e7eae8ea83491e8c203c2b192edcf5 upstream. The upper/lower connection thresholds for dest can be changed, so use ip_vs_dest_update_overload() to properly update the dest overload flag. The thresholds were not limited, fit them in the 0 .. INT_MAX range as already done in ipvsadm. As the thresholds are also read when connections are created and expired, use WRITE_ONCE/READ_ONCE to access them. As the lower threshold is optional, use (u - (u >> 2)) to calculate the 75% default value based on the upper threshold by preserving the integer rounding, as suggested by Yizhou Zhao. Trigger flag update when totalconns reaches one of the thresholds and use dst_lock to serialize the updating. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Julian Anastasov Signed-off-by: Yizhou Zhao Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 59b90c17bec5b0fdf7b482c96a40d4285eed9340 Author: Julian Anastasov Date: Fri Jul 31 22:27:41 2026 +0800 ipvs: add totalconns for dest commit 04d2feaed8d0103c498727191ba04001d5100e67 upstream. Replace the inactconns dest counter with totalconns, now inactconns can be obtained from totalconns - activeconns. This reduces the atomic inc/dec ops for TCP/SCTP from 6 to 4 if the connection is established and then closed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Julian Anastasov Signed-off-by: Yizhou Zhao Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e7f34f29b330265d456943bf0b984dcecfcef9af Author: Zhiling Zou Date: Wed Jul 29 21:56:59 2026 +0800 ipvs: stop estimator after disabled calc phase commit 558f67f1340f803a346ecd14a69c49653111c5f4 upstream. IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference. Fixes: 705dd3444081 ("ipvs: use kthreads for stats estimation") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 27f3924061592d0ef6b04e16f48754b6cb6adf27 Author: Lincoln Wallace Date: Mon Aug 3 10:50:21 2026 -0300 ima: fix out-of-bounds read in xattr_verify() commit 5ff232d31106f45ac87c3b64e1d35a0667777797 upstream. The digest-length check in xattr_verify() mixes int and size_t: if (xattr_len - sizeof(xattr_value->type) - hash_start >= iint->ima_hash->length) sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns "1 - 1 - 1" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it. Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is. Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur. Fixes: 3ea7a56067e6 ("ima: provide hash algo info in the xattr") Cc: stable@vger.kernel.org Signed-off-by: Lincoln Wallace Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit c5bf8cd148cfea948cfa3db71da427294b20db0f Author: Lorenzo Stoakes (ARM) Date: Thu Jul 23 16:16:31 2026 +0100 mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF commit 26444eb71465c9934d9d418ef69c43f61185329b upstream. Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty race between ptdump and vmap when attempting to map a huge P4D, PUD or PMD entry: * ptdump walks kernel page table ranges it doesn't own. * When vmap maps ranges it tries to promotes existing ones to huge page tables in vmap_try_huge_[p4d,pud,pmd]() at P4D, PUD and PMD level, freeing the lower page table in [p4d,pud,pmd]_free_[pud,pmd,pte]_page() when it succeeds. Both of these things can happen at the same time and as a result ptdump can access a freed page table, resulting in a use-after-free and memory corruption. This is possible because while ptdump_walk_pgd() holds both the mem hotplug lock and the mmap write lock before invoking walk_page_range_debug(), vmap takes no relevant locks at all. Fix this by holding the mmap read lock in vmap_try_huge_*() when freeing page tables. The read lock is sufficient: ptdump is the only walker that must be excluded and it holds the mmap write lock. Other holders of the read lock may run concurrently, but each exclusively owns the range it operates on and cannot reach the page tables freed here. We also hold the lock while assigning the huge page table entry, which means page table walkers observe only the huge or non-huge page table entry. We use a trylock to prevent ptdump from blocking vmap making forward progress. This is fine because it's an optimisation in any case, and thus the vmap can safely proceed regardless. All other kernel page table walkers that touch vmalloc ranges either exclusively own the memory walked or acquire the mmap lock, so this correctly excludes those walkers. One wrinkle here is commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which addresses the issue for arm64 only by explicitly acquiring the mmap read lock on kernel page table freeing should a concurrent ptdump be in progress. This is problematic as vmap may acquire the mmap read lock prior to ptdump attempting to acquire an mmap write lock, leading to a deadlock when the mmap read lock is slept upon on page table freeing due to rwsem anti-starvation. We work around this by predicating the mmap lock being taken on !CONFIG_ARM64 for the time being. With this patch applied, a follow up will partially revert commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump") and at that stage remove the arm64 ifdeffery. We also update walk_page_range_debug() to assert the mmap write lock unconditionally and update the comment here to reflect this change. The issue has existed as long as ptdump was available and vmap freed page tables when promoting to a huge leaf entry, that is, since commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") for huge ioremap, and commit 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings") for huge vmalloc. Since the former is the earlier of the two we choose that for our Fixes tag. We also define a guard class for mmap_read_trylock() so we can use cleanup.h to make the scope handling cleaner in the implementation. This patch is based on work by David Carlier (linked), with gratitude! Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-0-8cc77dcc0018@kernel.org Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-1-8cc77dcc0018@kernel.org Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a287988.39669fcc.33b062.00a0.GAE@google.com/T/ Link: https://lore.kernel.org/linux-mm/20260706203128.162335-1-devnexen@gmail.com/ Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Dev Jain Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Cc: Cc: Andy Lutomirski Cc: "Borah, Chaitanya Kumar" Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Liam R. Howlett Cc: Michal Hocko Cc: Peter Zijlstra Cc: Ryan Roberts Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Toshi Kani Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bd3c4108a56de34380edab670065e86283cb3029 Author: Dmitry Torokhov Date: Wed Jul 29 11:30:45 2026 -0700 Input: evdev - fix information leak in evdev_pass_values() commit 90f305f2c7a30257c683e13f4bf7c798eea992a0 upstream. In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary. Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ampGGKo4UMKru6f5@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b664592e9ba8c47c9e23408db7ba52eb9f946c8a Author: Joshua Rogers Date: Fri Jul 31 09:56:16 2026 +0200 vt: stabilize tty reference in kbd_keycode with tty_port_tty_get commit e25d47a526939ad44b75f778b8a7500562b84fc1 upstream. kbd_keycode() reads vc->port.tty without acquiring a tty reference, racing against con_shutdown() which clears port.tty under a different lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference for the duration the tty pointer is needed. Assisted-by: AISLE:Snapshot Signed-off-by: Joshua Rogers Cc: stable Link: https://patch.msgid.link/20260731-tty-vt-stuff-v1-1-be99b9da8e30@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a1c31e026c93e378e297a8df8328983d3013a59f Author: Joshua Rogers Date: Fri Jul 31 09:56:17 2026 +0200 vt: add permission check for KDSKBMETA ioctl commit a7ad0034453ba4c353f9b8f810ee2569de33d283 upstream. KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Link: https://patch.msgid.link/20260731-tty-vt-stuff-v1-2-be99b9da8e30@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2c7496124e94c7f9c3daa5c5b1fb563ca9d62c45 Author: Doruk Tan Ozturk Date: Sun Aug 2 14:06:02 2026 +0200 net: usb: ipheth: fix carrier_work UAF on disconnect commit fde39b8a521780391fb4e5bda2c0aa4928947f12 upstream. ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: else schedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai). Fixes: bb1b40c7cb86 ("usbnet: ipheth: prevent TX queue timeouts when device not ready") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260802120602.42595-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 58733b1dd46bb231d9d279c132a20ee46da1b664 Author: Yi Cong Date: Wed Jul 29 11:04:36 2026 +0800 net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup() commit 1f428e30947395d9b9aacee03e25a4e6cfcad7a4 upstream. When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb. usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the "drop" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure). Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function. Fixes: 16b1c4e01c89 ("net: usb: ax88179_178a: add TSO feature") Cc: stable@vger.kernel.org Signed-off-by: Yi Cong Link: https://patch.msgid.link/20260729030436.3420477-1-cong.yi@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d328fdc607fa1bb668ad512e1c918a120f78f337 Author: Sonali Pradhan Date: Mon Jul 20 16:56:54 2026 +0000 usb: gadget: f_ncm: Use unsigned int for ndp_index commit 6b1c8a9403a26cb0fed7a648916c74dc236da591 upstream. The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function. Fixes: 370af734dfaf ("usb: gadget: NCM: RX function support multiple NDPs") Cc: stable Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260720165654.2224591-1-sonalipradhan@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2dfefdd498ab4fb5ee0495f79db773ec01dc4ec3 Author: Pawel Laszczak Date: Mon Jul 20 13:11:58 2026 +0200 usb: cdnsp: fix incorrect endian conversions for APB timeout register commit 50b303f3d0f7de543ee90d50879970783d06da33 upstream. readl() already returns a CPU-endian value. Passing its return value to le32_to_cpu() is therefore redundant and causes an incorrect double byte swap on big-endian systems. Similarly, writel() expects a CPU-endian value, so passing the result of cpu_to_le32() is incorrect. Remove the unnecessary conversions and operate on the MMIO register value as a CPU-endian u32. Fixes: 241e2ce88e5a ("usb: cdnsp: Fix issue with resuming from L1") Suggested-by: Arnd Bergmann Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Arnd Bergmann Link: https://patch.msgid.link/20260720-endian-fix-v1-v1-1-b5681fa1ea9f@cadence.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 6e4c09bea8e9c2f41196b503daf205e5dd56eb4d Author: Xu Rao Date: Mon Jul 13 17:32:37 2026 +0800 thunderbolt: icm: Preserve USB4 proxy data-valid bit commit e48844ece5e3ed1d1eb865f6da2b16f62cd9f86d upstream. The ICM USB4 switch operation request encodes two values in request.data_len_valid: bit 4 marks the data payload valid, while bits 3:0 hold the payload length in dwords. A zero length with the valid bit set represents the full 16-dword data array. icm_usb4_switch_op() sets the valid bit when a transmit payload is present. For payloads shorter than the full 16 dwords, it then assigns the length to the whole field and clears the valid bit that was just set. The payload is still copied into the request, but the descriptor sent to firmware marks that data as invalid. This affects USB4 router operations that send short payloads through the firmware connection manager. In particular, USB4 NVM writes can send a short final block when the image size is not aligned to the 64-byte proxy payload size. Firmware may then ignore or reject that final block, while full 16-dword blocks are unaffected because they are encoded as length 0 with the valid bit set. OR the short payload length into data_len_valid so the valid bit is preserved. Fixes: 9039387e166e ("thunderbolt: Add USB4 router operation proxy for firmware connection manager") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 2f73a065791d2a8e3f0bdf29248e33600359e865 Author: Aleksandr Nogikh Date: Fri Jul 31 10:15:20 2026 +0000 usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() commit c2f811314be351d86b6ab41e9297ae80d8da6f86 upstream. If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed). Fixes: 1b0e61465234 ("[PATCH] USB ATM: driver for the Conexant AccessRunner chipset cxacru") Cc: stable Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+c9dff578c3a41775176a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c9dff578c3a41775176a Link: https://syzkaller.appspot.com/ai_job?id=75fec6f2-c8a6-43b1-b184-4d26baba86cc Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/91edfa4c-a63d-400c-9f00-31f3e1f98c00@mail.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit ebfd1e82ab0a6d26efd9bdd89de899215851f5bf Author: Jiangshan Yi Date: Wed Jul 22 18:18:10 2026 +0800 usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg commit 7e22c9f79b200672f3e477421b6c9050d8cf70a5 upstream. ibuf_len is the bulk IN (receive) buffer size, but the EMSGSIZE check in usbio_bulk_msg() compares it against txbuf_len — the bulk OUT endpoint size. Both are taken independently from different endpoints in usbio_probe(), so the check is wrong when they differ. Use rxbuf_len for the IN direction. This matches the buffer that actually holds the response data. Fixes: 121a0f839dbb ("usb: misc: Add Intel USBIO bridge driver") Cc: stable Signed-off-by: Jiangshan Yi Tested-by: Antti Laakso Link: https://patch.msgid.link/20260722101810.458634-1-yijiangshan@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 04b71290fb4190152dc2658bb6f4f34dfa6f6d64 Author: Ishaan Dandekar Date: Sun Aug 2 17:31:29 2026 +0530 usb: quirks: Add ShanWan gamepad to quirk list commit f3988e68fc089f6a5883f4f807955a3825bb7d45 upstream. The ShanWan Wireless Gamepad (dongle ID 2563:0575) crashes with a -71 EPROTO error during standard enumeration because it expects a 255-byte initial configuration request. Add this device to the quirk list to use the USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE flag. Signed-off-by: Ishaan Dandekar Cc: stable Link: https://patch.msgid.link/20260802120128.38302-1-ishaan.dandekar@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1740fd2aaa8fda02e857943ada6a434b891add79 Author: Nikhil Solanke Date: Wed Jul 29 01:21:57 2026 +0530 usb: core: Add quirk for 255-bytes initial config read commit 152f174a13618bec1f842d2deb69245cb2ace51f upstream. Certain third-party USB game controllers exposing (or spoofing) an Xbox 360-compatible interface (VID:PID 045e:028e) fail to enumerate under Linux. The device disconnects from the bus without responding to the initial GET_DESCRIPTOR(CONFIGURATION) request, and the kernel logs 'unable to read config index 0 descriptor/start: -71'. The device then falls back to a secondary Android HID mode (with a different VID:PID), losing XInput functionality including rumble support. The failure reproduces across multiple machines, host controller types, and kernel versions including current mainline and LTS. The device enumerates correctly and remains in XInput mode under Windows. Notably, the device enumerates correctly in Android mode when the same 9-byte request is issued for that mode's configuration descriptor, confirming the firmware bug is specific to the XInput mode. usbmon traces from Linux and Wireshark/USBPcap traces from Windows are identical up to the point of failure, with no visible protocol-level difference explaining the divergence. The root cause was identified when Michal Pecio discovered via a QEMU bus-level capture that Windows does not use wLength=9 for the initial config descriptor request; it uses wLength=255. Alan Stern subsequently confirmed this with a bus analyzer on a different USB 2.0 device, and Michal verified the behavior goes back to Windows 95 OSR2.1. So, add a new quirk flag USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE which causes usb_get_configuration() to issue a 255 byte sized configuration request instead of USB_DT_CONFIG_SIZE (9) for the initial GET_DESCRIPTOR(CONFIGURATION) request, mimicking long-standing Windows behavior. This patch intentionally does not add any new VID:PID entries using this quirk. Some affected Xbox 360-compatible controllers spoof Microsoft's VID:PID, while genuine Microsoft controllers already enumerate correctly and do not require this quirk. Other affected clone devices use their own VID:PID pairs and can be added individually as they are identified. Suggested-by: Alan Stern Suggested-by: Michal Pecio Closes: https://lore.kernel.org/linux-usb/CAFgddh+JWdT4LLwMc5qjM8q_pBu-fRo2qADR5ovAKoGHWMQrRw@mail.gmail.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Acked-by: Alan Stern Signed-off-by: Nikhil Solanke Link: https://patch.msgid.link/20260728195158.65162-2-nikhilsolanke5@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 0a235379825e1a6194e43861ee6658e5fc35686d Author: Baul Lee Date: Wed Aug 5 10:34:41 2026 +0900 ALSA: usb-audio: fix OOB write on Type II inbound URBs commit 69ee44e1a23be62318189dc4b37fa4ad94053269 upstream. data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: u->packets = urb_packs; u->buffer_size = maxsize * u->packets; if (fmt->fmt_type == UAC_FORMAT_TYPE_II) u->packets++; /* for transfer delimiter */ u->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: offs = 0; for (i = 0; i < urb_ctx->packets; i++) { urb->iso_frame_desc[i].offset = offs; urb->iso_frame_desc[i].length = ep->curpacksize; offs += ep->curpacksize; } urb->transfer_buffer_length = offs; urb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013441.38245-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4034ef247a9dde3f56660b01f0c3280dac6b1274 Author: Dmitry Torokhov Date: Mon Aug 3 18:41:49 2026 -0700 Input: evdev - sanitize event type index when fetching event masks commit 3abd29c61d2ef37c4102cf755b18be53bb9dbea6 upstream. The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array. Reported-by: "Wagenaar, C.C.J. (Chris)" Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.6-flash Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/anFCAfvxwXB5eJF1@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8b444b126cd8e4473e652f529753ed4dd1360a9c Author: Dongli Zhang Date: Sun Aug 2 15:46:12 2026 -0700 net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp() commit 3874892dd27d5387aa9a06f58d9060f18f351d24 upstream. The commit 4f61f133f354 ("net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit(). Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct") Cc: stable@vger.kernel.org Signed-off-by: Dongli Zhang Reviewed-by: Willem de Bruijn Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260802224612.264563-1-dongli.zhang@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fad7cecb5c2c04bacaebc54ea56b30abc70399ed Author: Mehmet Fide Date: Mon Aug 10 14:39:02 2026 +0200 net: fec: do not release NULL pages when RX buffer allocation fails fec_enet_alloc_rxq_buffers() leaves the loop as soon as page_pool_dev_alloc_pages() returns NULL and jumps to err_alloc, which calls fec_enet_free_buffers(). That helper walks the whole ring and hands every rx_skb_info[i].page to page_pool_put_full_page(), including the entries the allocation loop never reached. Those are still NULL, because the queue was allocated with kzalloc(), and page_pool_put_full_page() dereferences the page, so an open that runs out of memory oopses instead of returning -ENOMEM: Unable to handle kernel NULL pointer dereference at virtual address 00000014 when read Internal error: Oops: 5 [#1] SMP ARM CPU: 0 PID: 384 Comm: connmand Not tainted 6.18.43 #1 Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) PC is at fec_enet_free_buffers+0xb0/0x2a8 Call trace: fec_enet_free_buffers from fec_enet_open+0x1e0/0x504 fec_enet_open from __dev_open+0x114/0x238 __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x44/0x74 dev_change_flags from devinet_ioctl+0x3a4/0x768 Seen on a Colibri VF50, 128 MiB of RAM, on the first ifup after boot. Skip the entries that hold no page, and clear the ones that do after releasing them, so that a later failed open cannot release the same page a second time. Mainline is not affected. Commit a2ae70c0efe4 ("net: fec: add fec_alloc_rxq_buffers_pp() to allocate buffers from page pool") replaced this loop with fec_free_rxq_buffers(), which skips and clears the empty entries. That commit is part of the XDP zero copy series and is not a stable candidate, so this is the equivalent minimal fix for 6.18.y. Fixes: 95698ff6177b ("net: fec: using page pool to manage RX buffers") Cc: stable@vger.kernel.org Signed-off-by: Mehmet Fide Signed-off-by: Sasha Levin commit c768fb2e43c8ad70089f599ca0ac876e3a6a4e4f Author: Guenter Roeck Date: Tue Aug 4 17:30:42 2026 -0700 hwmon: (ltc4282) Fix parsing adi,current-limit-sense-microvolt [ Upstream commit 335698fd7f60b6707b21fda725f97f35fa956b07 ] ltc4282_parse_dt() evaluates the wrong variable when parsing the current limit. When the adi,current-limit-sense-microvolt property is parsed into st->vsense_max, the subsequent switch statement evaluates the unrelated val variable instead of st->vsense_max: drivers/hwmon/ltc4282.c:ltc4282_parse_dt() { ... ret = device_property_read_u32(dev, "adi,current-limit-sense-microvolt", &st->vsense_max); if (!ret) { int reg_val; switch (val) { case 12500: reg_val = 0; break; ... } Because val holds a small integer representing vin_mode (from 0 to 3), it never matches any of the valid current limit cases. This causes it to always fall through to the default error case, return -EINVAL, and aborts probe initialization for any device tree using this property. Validate st->vsense_max instead to fix the problem. Reported-by: Sashiko Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Reviewed-by: Nuno Sá Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit de58b90a4d1417c15b693eb04c0ce6bc925d84c6 Author: Guenter Roeck Date: Tue Aug 4 16:26:05 2026 -0700 hwmon: (ltc4282) Clamp negative current limits [ Upstream commit e253dd5f9f6d875a317895bf43ec9534ed7523cb ] When a negative value is passed to ltc4282_write_curr(), the signed long val is cast directly to u64: drivers/hwmon/ltc4282.c:ltc4282_write_curr() { /* need to pass it in millivolt */ u32 in = DIV_ROUND_CLOSEST_ULL((u64)val * st->rsense, DECA * MICRO); ... } This cast converts negative inputs into large positive values. The subsequent division result overflows the u32 in variable, truncating to a pseudo-random positive value. When this is passed to ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead of zero. Clamp val to 0 and to the maximum supported upper limit before the cast and assign the result to a 64-bit temporary variable before the division to avoid the underflow and an also possible overflow. Reported-by: Sashiko Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Reviewed-by: Nuno Sá Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 124bd4b006199c288e75c24ced05c4ffadc41b63 Author: Guenter Roeck Date: Tue Aug 4 15:42:42 2026 -0700 hwmon: (ltc4282) Avoid overflow in maximum power calculation [ Upstream commit edd11a94335747423569500a194c6eaa915f2963 ] During device initialization in ltc4282_set_max_limits(), the calculation of the maximum power limit can suffer from a 32-bit integer overflow. static int ltc4282_set_max_limits(struct ltc4282_state *st) { ... st->power_max = DIV_ROUND_CLOSEST(st->vsense_max * DECA * MILLI, st->rsense) * st->vfs_out; ... } The result of DIV_ROUND_CLOSEST() evaluates to a 32-bit unsigned integer on 32-bit architectures. This result is then multiplied by st->vfs_out, which is a 16-bit unsigned integer. According to C promotion rules, since both operands are 32-bit or smaller, the multiplication is performed in 32-bit precision. If the device is configured with a low sense resistor value via the device tree (for example, 100 nano-ohms, resulting in st->rsense = 1) and the voltage is high, the division result can reach 343,750,000 and st->vfs_out can be 33,280. The product of these values is approximately 11.44 trillion, which exceeds the maximum capacity of a 32-bit integer and overflows before being stored in st->power_max. This overflow causes a truncated value to be assigned to st->power_max and written to the hardware limit register. An incorrect maximum power limit can trigger spurious power-bad faults or alarms, which may lead to the shutdown of the monitored power rail. Avoid the problem by calculating and storing the maximum power using 64-bit variables. Reported-by: Sashiko Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Reviewed-by: Nuno Sá Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 678a76c8fd33ddecc6c6b4935383366595fa8b56 Author: Qingshuang Fu Date: Wed Aug 5 14:16:45 2026 +0800 hwmon: (ads7828) Fix external VREF regulator handling [ Upstream commit fddb5ceaf901b050ed2a1a7deeecbf97e003435a ] The driver currently has two issues with the external VREF regulator handling in ads7828_probe(): 1. All errors from devm_regulator_get_optional() are ignored, causing the driver to incorrectly fall back to internal VREF even for transient errors like -EPROBE_DEFER or genuine failures like -ENOMEM. 2. The external regulator is never enabled. The driver calls regulator_get_voltage() without first calling regulator_enable(), so the VREF pin may remain unpowered if the regulator is not configured as always-on. Fix both issues by switching to devm_regulator_get_enable_read_voltage(), which handles regulator get, enable, and voltage read in one call. Only -ENODEV (no regulator specified in device tree) should trigger the fallback to internal VREF. All other errors are propagated to the caller. Fixes: a8ddfea09566 ("hwmon: (ads7828) Accept optional parameters from device tree") Signed-off-by: Qingshuang Fu Link: https://lore.kernel.org/r/20260805061645.1331652-1-fffsqian@163.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 5ee1f603a64bdc9b8196bc0aec46a086abacd2ae Author: Wilken Gottwalt Date: Wed Aug 5 07:19:20 2026 +0000 hwmon: (corsair-psu) fix possible out-of-bounds access on missing string termination [ Upstream commit 36c4d73ce05d1d8896c2669eb0730d35a02a2ec1 ] In theory it could be possible that the REPLY_SIZE sized buffers for holding the vendor and product strings could be end up missing the null termination (for example by malicious hardware built on purpose) required by the seq_printf() call. That limits the debugfs printf calls to a maximum string length of REPLY_SIZE. Fixes: d115b51e0e567 ("hwmon: add Corsair PSU HID controller driver") Signed-off-by: Wilken Gottwalt Link: https://lore.kernel.org/r/anLj9gPWRoRDbQBV@monster.localdomain Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 29fe74c9aa69d78c1c6a3930f1d9fc5db71a6eed Author: Hongyan Xu Date: Thu Aug 6 14:06:13 2026 +0800 watchdog: at91sam9_wdt: prevent timer rearm during teardown [ Upstream commit 8444d66aa6b6e7fe0a26fa1a00a11cb4d0523783 ] at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed. Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer. Fixes: 5161b31dc39a ("watchdog: at91sam9_wdt: better watchdog support") Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/20260806060613.1830-1-getshell@seu.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6d1d3ca6c8f4a9ef0f8b7a9b591b2586d16babb5 Author: Maximilian Immanuel Brandtner Date: Wed Aug 5 08:22:48 2026 +0200 tls: don't abort the connection on signal-interrupted sends [ Upstream commit af0e5cdd031f4f4a8f6d4160bfbda4f36872b0ed ] When a signal interrupts a blocking send, tls_tx_records() treats the resulting -ERESTARTSYS as a transmission failure and marks the socket errored via tls_err_abort() with the raw error code. Later syscalls return the kernel-internal errno 512 (ERESTARTSYS) to userspace, as the signal it stems from is no longer pending during syscall exit and thus never translated. An interrupted send is not a connection error: the partially sent record stays queued and is resent later. Interrupt error codes are therefore excluded from the abort in the same way as -EAGAIN. Fixes: b341ca51d267 ("tls: Fix tls_sw_sendmsg error handling") Signed-off-by: Maximilian Immanuel Brandtner Link: https://patch.msgid.link/20260805063109.1772314-1-maxbr@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18d704bdd809377dfd81a3c2f42426763b5da227 Author: Xin Long Date: Wed Aug 5 11:18:40 2026 -0400 sctp: clear control chunk transport if it is being removed [ Upstream commit c9158ceaf27780ef64534ad72f44ffde3f8ccc49 ] sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport. Fixes: 8a07eb0a50ae ("sctp: Add ASCONF operation on the single-homed host") Reported-by: Daniele Linguaglossa Signed-off-by: Xin Long Link: https://patch.msgid.link/7e1168cb722132152a29d47e5eafaeac4a3bf6f3.1785943120.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f77c1ab382188f5b51982fab6d913443b6dc59f Author: Eric Dumazet Date: Wed Aug 5 13:15:08 2026 +0000 net/atm: fix slab-out-of-bounds read in vcc_setsockopt() [ Upstream commit d0c80dbb970439bd2eeb0e5effff8c16a5f4e1e3 ] vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL; If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space. Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size. Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+53ecc09fb81df10ef4de@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=53ecc09fb81df10ef4de Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260805131508.3227331-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc3021284050ecb3bba8a7851340cedcb5037928 Author: Alexandra Winter Date: Wed Aug 5 15:10:43 2026 +0200 s390/ism: Fix UAF of sba and ieq during ism_dev_exit() [ Upstream commit b1896543ce59c4258625a35cf41e23a9a1f80ea2 ] A ism interrupt handler can be active in parallel with ism_dev_exit(), accessing freed data structures. No new interrupts will be generated after unregister_ieq(). Drain ongoing interrupt handlers by free_irq(), before freeing ism data structures. Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory") Signed-off-by: Alexandra Winter Link: https://patch.msgid.link/20260805131043.954639-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8fa684db8709b5b97ff066b9d26ec3e92d662d99 Author: Bhargava Marreddy Date: Wed Aug 5 15:10:22 2026 +0530 bnge: Fix resource leak in bnge_init_nic() error path [ Upstream commit bfec39ff1484b4e9f7d93bc4580fdb634bbc7d19 ] If bnge_init_chip() fails, bnge_init_nic() jumps to err_free_ring_grps and returns immediately, skipping cleanup for RX ring pair buffers. Remove the early return so execution falls through to err_free_rx_ring_pair_bufs to properly free resources on error. Fixes: 23df6aebf803 ("bng_en: Allocate stat contexts") Signed-off-by: Bhargava Marreddy Reviewed-by: Dharmender Garg Reviewed-by: Rajashekar Hudumula Link: https://patch.msgid.link/20260805094022.15487-1-bhargava.marreddy@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a837deeaa37cc3f0e8c4e5c096787047f272c956 Author: Hongyan Xu Date: Thu Aug 6 14:06:28 2026 +0800 ata: pata_sl82c105: fix bridge revision use-after-free [ Upstream commit 7700a31039cdc6715cb6cce7e7a664ee4e945f67 ] pci_get_slot() returns a referenced PCI device. Commit 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") replaced a configuration-space read with direct access to the cached revision field, but left that access after pci_dev_put(). The bridge may therefore be freed before its revision is read. Read the revision before dropping the reference. Fixes: 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") Signed-off-by: Hongyan Xu Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 4dd71cb0d23d40cb58fe4261c7bd183dca66caa0 Author: Fan XinRan Date: Mon Aug 3 14:38:50 2026 +0000 net: thunderbolt: Tear down DMA paths before stopping the rings [ Upstream commit 68bf02b6b4ad3f748c6db71fd77b6c0402d252f4 ] tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable DMA paths only after rings are enabled") moved the path enable to the end of tbnet_connected_work() and documented why: /* Both logins successful so enable the rings, high-speed DMA * paths and start the network device queue. * * Note we enable the DMA paths last to make sure we have primed * the Rx ring before any incoming packets are allowed to * arrive. */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Fan XinRan Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260803-b4-tbnet-teardown-v2-1-27de6a13ca2d@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 78e5ebcd1c10ed7c8bda0a99e0abd5b62da86d67 Author: Sidraya Jayagond Date: Mon Aug 3 09:07:01 2026 +0200 net/smc: fix TOCTOU race between smc_listen_out() and listener close [ Upstream commit 185a4caeecabc150106deda1da170b09f2ad803f ] smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock. Fixes: fd57770dd198 ("net/smc: wait for pending work before clcsock release_sock") Reviewed-by: Mahanta Jambigi Signed-off-by: Sidraya Jayagond Reviewed-by: Breno Leitao Reviewed-by: Dust Li Link: https://patch.msgid.link/20260803070701.126339-1-sidraya@linux.ibm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c8f256dc849205ccb2bd78bd99a3497b972b44e0 Author: Eric Dumazet Date: Tue Aug 4 15:20:48 2026 +0000 net: remove WARN_ON_ONCE() from sk_mc_loop() [ Upstream commit b8a39a09ae4eaae04309e1e38ed6a1101d967496 ] sk_mc_loop() can be called for sockets that are neither AF_INET nor AF_INET6 (e.g. AF_PACKET sockets when sending packets via raw/packet socket over virtual devices such as VRF or ipvlan). In such cases, sk_family is not AF_INET/AF_INET6 and sk_mc_loop() falls through the switch statement and triggers WARN_ON_ONCE(1). Non-INET sockets do not support IP_MULTICAST_LOOP or IPV6_MULTICAST_LOOP options, so loopback should default to true without generating a warning. Fixes: f60e5990d9c1 ("ipv6: protect skb->sk accesses from recursive dereference inside the stack") Reported-by: syzbot+22c3218a6fa219e47321@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a72024c.13623e66.bdc14.0019.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260804152048.2134341-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 363e048a9d0a6c245cbc348c8a220170afed046a Author: Pengpeng Hou Date: Fri Jul 31 22:19:06 2026 +0800 net: prestera: validate firmware header length [ Upstream commit 8ae344eb540af3f457179b52bc6061416752485c ] prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields. Fixes: 4c2703dfd7fabb ("net: marvell: prestera: Add PCI interface support") Signed-off-by: Pengpeng Hou Acked-by: Elad Nachman Link: https://patch.msgid.link/20260731141500.1-prestera-v2-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 02226af69362758046822840fc6a497f5de33f00 Author: Henry Martin Date: Mon Aug 3 12:36:18 2026 +0800 net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length [ Upstream commit afa58b7384913c8773d837acdb07b035690ec5d2 ] ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab. Fixes: 9771b8ccdfa6 ("net/ncsi: Extend NC-SI Netlink interface to allow user space to send NC-SI command") Reported-by: Henry Martin Signed-off-by: Henry Martin Link: https://patch.msgid.link/20260803043618.3210301-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 12afa450a6a6c0cce2c42b7545a9958f62d8a00c Author: Eric Dumazet Date: Tue Aug 4 09:33:28 2026 +0000 netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref() [ Upstream commit 8aecf0bbcc72605592134c917c222207d8f63ab0 ] Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps. Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset(): WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170 WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234 WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864 Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination. Fixes: 2a79fd3908ac ("netfilter: nf_flow_table: attach dst to skbs") Reported-by: syzbot+76d4e3a055aec3b007ec@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a71b141.9511d2ce.1fc5b9.033b.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Pablo Neira Ayuso Link: https://patch.msgid.link/20260804093328.1831847-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25d40cf9dab157d37cef181ac778daa735978efb Author: Pablo Neira Ayuso Date: Fri Oct 10 12:32:35 2025 +0200 netfilter: flowtable: consolidate xmit path [ Upstream commit b5964aac51e0c286a50e68225e0dfcf11fb554cb ] Use dev_queue_xmit() for the XMIT_NEIGH case. Store the interface index of the real device behind the vlan/pppoe device, this introduces an extra lookup for the real device in the xmit path because rt->dst.dev provides the vlan/pppoe device. XMIT_NEIGH now looks more similar to XMIT_DIRECT but the check for stale dst and the neighbour lookup still remain in place which is convenient to deal with network topology changes. Note that nft_flow_route() needs to relax the check for _XMIT_NEIGH so the existing basic xfrm offload (which only works in one direction) does not break. Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 8aecf0bbcc72 ("netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref()") Signed-off-by: Sasha Levin commit a66e869cf0c90c1e47ae75f72b6482acbfc808ff Author: Jiayuan Chen Date: Mon Aug 3 14:17:38 2026 +0800 tcp: fix TFO max_qlen accounting across reuseport migration [ Upstream commit a0ab2ba83e35159d81cec830a92e885ecf8139be ] A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen. Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.") Signed-off-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260803061739.134737-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6c24ec01fb76877f4791918c9062bc20cfab6e94 Author: Qing Luo Date: Tue Aug 4 10:55:14 2026 +0800 sctp: fix addip_serial increment on ASCONF_ACK allocation failure [ Upstream commit aa2e13ae8d3cbe2c15ef4f7e971b2de0832794aa ] In sctp_process_asconf(), when sctp_make_asconf_ack() fails to allocate the ASCONF_ACK chunk due to memory pressure, the code jumps to the done label where asoc->peer.addip_serial is unconditionally incremented. This leaves the peer's ASCONF (serial N) unacknowledged while the local endpoint now expects serial N+1. When the peer retransmits serial N, it falls into the serial < addip_serial + 1 branch , which attempts to look up a cached ACK for serial N. No cached ACK exists since the allocation failed, so the retransmission is silently discarded. The peer eventually times out and ABORTs the association. Move the addip_serial increment inside the if (asconf_ack) block so that the serial number is only advanced when the ASCONF_ACK is successfully created and cached. This way, on allocation failure, the serial number is unchanged and the peer's retransmitted ASCONF will be correctly re-processed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Qing Luo Acked-by: Xin Long Link: https://patch.msgid.link/20260804025514.241767-1-l1138897701@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e8f24b1e3fee9068f5289583cf65652a47062df Author: Keegan Freyhof Date: Fri Jul 31 12:09:37 2026 -0700 bnxt_en: Fix PTP PPS setting bug [ Upstream commit 80eaf88efec33ac77ed7726d066c4f2f932cc329 ] The existing driver logic is always turning on PTP_CLK_REQ_PPS regardless of the "on" parameter passed to bnxt_ptp_enable(). During shutdown, PTP_CLK_REQ_PPS may be turned off and this bug will do the opposite and may trigger a PCIe PTM request TLP. On some systems this can trigger a PCIe AER. Fix it by properly configuring PTP_CLK_REQ_PPS based on the "on" parameter. Fixes: 9e518f25802c ("bnxt_en: 1PPS functions to configure TSIO pins") Reviewed-by: Pavan Chebbi Signed-off-by: Keegan Freyhof Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260731190937.807270-6-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aab3b5f4d8ec8598606ee011e219ef824ae25ca0 Author: Michael Chan Date: Fri Jul 31 12:09:36 2026 -0700 bnxt_en: Disable EOP for TPA on all chips to prevent data corruption [ Upstream commit c3faf548a00f4c17100cc9204746975fa46a73b9 ] EOP (End of frame padding) on the AGG ring may cause overlapping of zero padding at the end of one segment with the next segment's data. If Relaxed Ordering (RO) is enabled, the zero padding may overwrite valid data in the next segment and corrupt the data. Older chips (P5 and older) do not automatically disable RO when EOP is enabled. On some ARM systems, data corruption was reported on 57508 (P5) chips with RO enabled. Always disable EOP on all chips on the AGG rings when TPA is enabled to fix the data corruption. Fixes: bfcd8d791ec1 ("bnxt_en: Add fast path logic for TPA on 57500 chips.") Reviewed-by: Pavan Chebbi Reviewed-by: Kalesh AP Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260731190937.807270-5-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a2e50924e57e336961c861521ba96f7ce54e548 Author: Shravya KN Date: Fri Jul 31 12:09:35 2026 -0700 bnxt_en: Refresh VNIC default ring on queue restart if needed [ Upstream commit 0b137529a8997caf67190ca1d71ba8bbdb44fbfb ] When a queue is restarted, refresh VNIC_CFG for all VNICs whose default RX ring is the restarted ring. This will eliminate this possible FW warning caused by a stale default ring in the VNIC: FW reported unknown error type 10 Fixes: 5ac066b7b062 ("bnxt_en: Fix queue start to update vnic RSS table") Reviewed-by: Kalesh AP Reviewed-by: Pavan Chebbi Signed-off-by: Shravya KN Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260731190937.807270-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f1a4e95e296b21ecae5447e6736618372f854d61 Author: Shravya KN Date: Fri Jul 31 12:09:34 2026 -0700 bnxt_en: Determine and store default RX ring in vnic structure [ Upstream commit 53f01cd594e223aabb538d5288e60111523c96f2 ] Each VNIC has a default RX ring. The purpose of the default RX ring is to provide a destination for any packets that cannot be parsed by the RSS logic. Up until now, the default RX ring is always Ring 0. We neglected to take care of this default RX ring when adding the queue restart feature. If ring 0 (default ring) is re-started, it may now have a new FW ring ID after freeing the old one and allocating a new one. The VNIC now may have a stale default ring and it may generate an internal exception. This exception may appear in dmesg: FW reported unknown error type 10 The best way to resolve this issue is to use a more appropriate ring for the default ring instead of always ring 0. Ring 0 may not even be in the RSS table, especially on a new RSS context. This patch adds the logic to determine and store the proper default RX ring for a VNIC. For an RSS VNIC, the default ring is the lowest ring number in the RSS table. The next patch will add proper logic to update the VNIC if the default ring changes after queue restart. Reviewed-by: Kalesh AP Reviewed-by: Pavan Chebbi Signed-off-by: Shravya KN Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260731190937.807270-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0b137529a899 ("bnxt_en: Refresh VNIC default ring on queue restart if needed") Signed-off-by: Sasha Levin commit 965c45be24e151d1f7e86ed3c99752fe0577a8bd Author: Shravya KN Date: Fri Jul 31 12:09:33 2026 -0700 bnxt_en: Move RSS table fill outside __bnxt_hwrm_vnic_set_rss() [ Upstream commit 1d0fc6c7ea49994b8ff50d02979d1e4207ec6c4f ] This is a refactor patch with no change in behavior. The caller will now fill the RSS table before calling __bnxt_hwrm_vnic_set_rss(). In the next patch, we'll add code to determine the default ring for the VNIC when we fill the RSS table. Reviewed-by: Kalesh AP Reviewed-by: Pavan Chebbi Signed-off-by: Shravya KN Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260731190937.807270-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0b137529a899 ("bnxt_en: Refresh VNIC default ring on queue restart if needed") Signed-off-by: Sasha Levin commit 88664c48d7d1eca8e1ac92da85c89c26af741cf1 Author: Bobby Eshleman Date: Mon Aug 3 16:47:29 2026 -0700 net/mlx5e: fix BQL reset on SQ re-activation [ Upstream commit e7386770be1bf810bcd6af39d1e4bfeab3408430 ] mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed(): kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc). In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset. Fixes: b2588ea40ec9 ("net/mlx5e: Implement queue mgmt ops and single channel swap") Signed-off-by: Bobby Eshleman Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260803-mlx5-bql-v3-1-a30d4c66fe1d@meta.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit beb47092fe8fc1b39d7e0e0905cafc3027b44310 Author: Alok Tiwari Date: Sat Aug 1 03:09:20 2026 -0700 bnge: use int for bnge_fix_rings_count() return value [ Upstream commit 2cbd8a4e5e09aa232a1f8d56ce3d070b18ab2b10 ] bnge_fix_rings_count() returns 0 on success or a negative errno on failure However, bnge_adjust_rings() stores its return value in a u16 variable, causing negative error codes such as -ENOMEM to be converted to a large positive value. Use an int for the return code variable so that error values are preserved and propagated correctly. Fixes: 627c67f038d2 ("bng_en: Add resource management support") Signed-off-by: Alok Tiwari Reviewed-by: Bhargava Marreddy Link: https://patch.msgid.link/20260801100923.1498570-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4901b23b5ca7b9b8005922655b880684d89bdb9e Author: Stefan Agner Date: Mon Aug 3 11:51:56 2026 +0200 net: stmmac: resume PHY before hardware setup when opening the interface [ Upstream commit 06232cb44bc8e81adc2f1d40a01bed830b607ea2 ] Since the referenced commit, changing the MTU on a running interface no longer disconnects and reconnects the PHY; __stmmac_release() merely stops phylink, which also suspends the PHY (BMCR power-down) when WoL is not enabled. __stmmac_open() then performs the DMA software reset in stmmac_hw_setup() before phylink_start() resumes the PHY again. IEEE 802.3 22.2.4.1.5 allows a PHY to stop its receive clock while powered down, and stmmac requires a running receive clock for the DMA software reset to complete (the phylink config sets mac_requires_rxc). On such setups, e.g. the RK3566-based Home Assistant Green with an RTL8211F-VD PHY in RGMII mode, any runtime MTU change now times out and leaves the interface dead: rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change In the field this is triggered by NetworkManager applying an MTU while activating the connection, breaking networking entirely. The same regression has also been reported on i.MX8MP and reproduced on SoCFPGA based systems. Resume the PHY in __stmmac_open() before the hardware setup, making it the counterpart of the phylink_stop() in __stmmac_release(), like stmmac_resume() already does for the same reason. phylink_start() also resumes the PHY, but only after stmmac_hw_setup(), and it cannot be moved before the hardware setup since it may bring the link up immediately from a workqueue, racing with the initialization (see the comment in stmmac_resume()). For the regular ndo_open path the PHY has just been attached and is not suspended, in which case phylink_prepare_resume() does nothing. Fixes: db299a0c09e9 ("net: stmmac: move PHY handling out of __stmmac_open()/release()") Link: https://github.com/home-assistant/operating-system/issues/4858 Tested-by: Alexander Stein Signed-off-by: Stefan Agner Tested-by: Maxime Chevallier Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260803095156.132827-1-stefan@agner.ch Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 99b7bcee01589bca0f181ce05516279ca50048b9 Author: Martin Kaiser Date: Tue Aug 4 21:46:35 2026 +0200 selftests/ftrace: refactor eprobes test to fix argument checks [ Upstream commit 6e3abef2a27e7402a94111c9eff85d887e64a309 ] The add/remove eprobe test installs an eprobe for the openat syscall and runs ls. It checks the filenames that were opened by ls against a whitelist and a blacklist. Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer") fixed access to some string fields in eprobes. This triggers test failures as the blacklist does not allow relative paths for the openat parameters. What makes this test unstable is the fact that the openat calls vary a lot between different systems. Refactor the test to make it more robust. "cd " will issue a chdir syscall with the target directory as parameter. Set an eprobe on the sys_enter_chdir event and filter for the exact directory name. Allow (fault) as fallback. Link: https://lore.kernel.org/all/20260804194705.760893-1-martin@kaiser.cx/ Fixes: 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202607151010.b68428e1-lkp@intel.com Signed-off-by: Martin Kaiser Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit a7a00ecf54243a05d23906078a2cf254e9a0040d Author: Guenter Roeck Date: Tue Aug 4 14:12:31 2026 -0700 hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations [ Upstream commit 0dabe8a56f772f0ece46d2597799f412c277d874 ] In lm25066_probe(), the PMBus coefficients for current and power are scaled based on the shunt resistor value. The calculation evaluates the multiplication using 32-bit arithmetic because info->m is an int and shunt is a u32: static int lm25066_probe(struct i2c_client *client) { ... info->m[PSC_CURRENT_IN] = info->m[PSC_CURRENT_IN] * shunt / 1000; info->m[PSC_POWER] = info->m[PSC_POWER] * shunt / 1000; ... } For large coefficients like 26882 (LM25056) or 15076 (LM5066i), a device tree shunt-resistor-micro-ohms value exceeding approximately 159,000 (159 mOhm, which is physically valid for low-current applications) causes the intermediate product to exceed UINT_MAX (4,294,967,295). This results in a silent wraparound before the division by 1000. Furthermore, if the wrapped value has the most significant bit set, converting it back to the signed int info->m results in negative coefficients. This logic error leads to drastically corrupted current and power readings, which can cause erratic thermal or power management behavior in the system. Fix the problem by using 64-bit operations for the multiply/divide operations. This can still overflow, but only for unreasonably large shunt resistor values. Reported-by: Sashiko Fixes: 94ee5fcc240fe ("hwmon: (pmbus/lm25066) Support configurable sense resistor values") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2e5ea8272ceae0b242ad07d1dff0e62bb7f534e6 Author: Qingshuang Fu Date: Tue Aug 4 15:48:42 2026 +0800 hwmon: (nzxt-smart2) Check return value of init_device() in probe [ Upstream commit d533882ce1060866a590257f2c77ee23eabef5b8 ] The init_device() call in nzxt_smart2_hid_probe() can fail because it sends HID output reports to the hardware to detect fans and set the update interval. If the hardware is not responding or the HID reports fail, init_device() returns a negative error code. However, the return value was ignored, causing the probe to continue and register an hwmon device even though the device was never properly initialized. This leads to an inconsistent state where the driver reports stale data or blocks on wait queues that will never be woken. The same function's return value is already checked in the reset_resume() handler, confirming the author's intent that errors should be propagated. Note that this fix was not possible before commit 59d104b54b0b ("hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop") because the out_hw_close error path was missing hid_device_io_stop(), which would have opened a use-after-free risk window. Fixes: 53e68c20aeb1 ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2.") Signed-off-by: Qingshuang Fu Link: https://lore.kernel.org/r/20260804074842.505923-1-fffsqian@163.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9fccf43f05317f24a94405e819e2b28bc1eeb943 Author: Marcin Bernatowicz Date: Thu Jul 9 09:59:45 2026 +0200 drm/xe/uc: Apply RCS/CCS yield policy to SR-IOV VFs [ Upstream commit d1643db3b037b57f2af7f85c3821d6fe69c492f6 ] VFs were missing the call to apply the global scheduling policy. Call xe_guc_submit_enable() during vf_uc_load_hw() to ensure VFs get the same policy enforcement as PF. Fixes: 26caeae9fb48 ("drm/xe/guc: Set RCS/CCS yield policy") Suggested-by: Michal Wajdeczko Signed-off-by: Marcin Bernatowicz Cc: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Reviewed-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260709075945.1337660-1-marcin.bernatowicz@linux.intel.com Signed-off-by: Michał Winiarski (cherry picked from commit f09360e857130f7ab7f069e2421e6b4a6e502531) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit d6222af7274f08e7a1848131dc30319993d8f377 Author: Jamal Hadi Salim Date: Sat Aug 1 08:56:32 2026 -0400 net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers [ Upstream commit a347304b2ca1a5377d5bd2d8a72e4b4f12afe648 ] Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create("u32") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create("flower") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind "flower" but tp->ops->kind is "u32") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable "not_lockless" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context. Fixes: 12db03b65c2b ("net: sched: extend proto ops to support unlocked classifiers") Reported-by: Feng Xue Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260801125632.360365-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a8139285c8925efe59af28a9169bb2fda91bff15 Author: Cen Zhang (Microsoft) Date: Thu Jul 30 18:20:06 2026 -0400 net/openvswitch: check Ethernet header length in key_extract() [ Upstream commit cf6f8b29befb92173659bcef6a441d274947bfae ] When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header. Fixes: 217ac77a3c25 ("openvswitch: allow L3 netdev ports") Reported-by: AutonomousCodeSecurity@microsoft.com Reviewed-by: Eelco Chaudron Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260730222006.118652-1-blbllhy@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a06e4611d45518896fbff4f45d9581578b107e91 Author: Jia Jia Date: Sun Jul 26 22:43:14 2026 +0800 vhost-scsi: reject feature changes after endpoint [ Upstream commit 42bc45df5905e2b7dccb72adaf7730f66cfbe03f ] vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates each command's protection scatterlist array (prot_sgl) according to the acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt when VHOST_SET_FEATURES changes that bit later. Although virtio feature bits must not change after feature negotiation, vhost_scsi_set_features() currently accepts such a request after the endpoint is active and updates acked_features. Enabling T10-PI after endpoint setup therefore leaves prot_sgl NULL while the I/O path follows the new feature bit. For a 129-page protection payload, vhost_scsi_mapal() passes the missing first chunk to sg_alloc_table_chained(): sg_alloc_table_chained(table, 129, first_chunk=NULL, nents_first_chunk=inline_sg_cnt) sg_pool_index() then hits: BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */ The kernel reported the following call trace and register state: Call Trace: ? __sg_alloc_table+0x1d8/0x250 ? __pfx_vhost_run_work_list+0x10/0x10 [vhost] sg_alloc_table_chained+0x59/0xf0 ? __pfx_sg_pool_alloc+0x10/0x10 ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi] vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi] ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi] vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi] vhost_run_work_list+0x8e/0xd0 [vhost] vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 RIP: 0010:0x4 CR2 = 0x4 RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202 RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081 VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only exception. Reject changes to any feature other than VHOST_F_LOG_ALL while the endpoint is active. This preserves the existing runtime log toggle while preventing feature-dependent command resources and data-path state from becoming inconsistent. Userspace must clear the endpoint before changing any other negotiated feature and set the endpoint up again afterward. Fixes: bf2d650391be ("vhost-scsi: Allocate T10 PI structs only when enabled") Signed-off-by: Jia Jia Reviewed-by: Stefan Hajnoczi Signed-off-by: Michael S. Tsirkin Message-ID: <20260726144314.1652934-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit 2417a498cf3fe64d06faf87e236eda98dd4f04e0 Author: Linfeng Sun Date: Mon Jul 27 16:18:41 2026 +0800 vhost-scsi: Validate T10 PI scatterlist counts [ Upstream commit d876c493fc4b811941bfeb4c80beb2dfc4bf025e ] When T10 PI is negotiated, vhost-scsi splits protection bytes from the data iterator before mapping the request scatterlists. A malformed request can claim protection bytes that cover or exceed the full payload length. The former leaves no data bytes to map, while the latter underflows exp_data_len before advancing the iterator. Both cases can let a zero data SGL count reach sg_alloc_table_chained(), which triggers BUG_ON(!nents). Reject protection lengths that cover or exceed the payload before subtracting prot_bytes and advancing the iterator. Also propagate negative errors from the protection SGL calculation before calling the allocator, matching the data SGL path. Fixes: bca939d5bcd0 ("vhost-scsi: Dynamically allocate scatterlists") Suggested-by: Jia Jia Signed-off-by: Jia Jia Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun Message-ID: <20260727081841.923151-1-slf@hdu.edu.cn> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit cd2f1d9fe8a507c2dc86ad326fe221f121c47734 Author: Toke Høiland-Jørgensen Date: Wed Jul 29 21:14:16 2026 +0200 net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter [ Upstream commit 2a33516f9ef59ad11844d4fc152f889449b5daf3 ] The sch_cake ACK filter parses packets to find the TCP header and filter duplicated ACKs if the flow is backlogged. The parsing code contains a WARN_ON(1) which can be triggered by a malformed IP header in certain cases. Depending on the system configuration, this leads either to either spamming dmesg with warnings, or a panic if panic_on_warn is set. The code already correctly skips the offending packet in the branch that triggers the warning, so the WARN_ON itself doesn't really serve any purpose. So just drop it altogether to avoid the inconvenient side effects. Fixes: 8b7138814f29 ("sch_cake: Add optional ACK filter") Reported-by: Zhiling Zou Reported-by: Ren Wei Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260729191417.45665-1-toke@toke.dk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 64d322c288577793eedd352b96ef75234ed380fe Author: Xuanqiang Luo Date: Thu Jul 30 17:35:54 2026 +0800 udp: fix potential use-after-free in tunnel segmentation [ Upstream commit d0f86fb36eb260abd10007b62c9dcc1028e03e61 ] __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free. Fixes: dbef491ebe7f ("udp: Use uh->len instead of skb->len to compute checksum in segmentation") Signed-off-by: Xuanqiang Luo Reviewed-by: Antoine Tenart Link: https://patch.msgid.link/20260730093554.68127-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fd121971912dee2f5af1efec64462ac722deb17 Author: Stanislav Fomichev Date: Mon Jul 27 09:19:59 2026 -0700 xsk: validate metadata when processing requests [ Upstream commit 849b1664dbda1cf6c63e0fd4f9dec23782b8c851 ] The zero-copy path validates TX metadata while obtaining the descriptor context, then reads it again later when preparing the hardware request. User space can change the metadata between those operations and bypass the original validation. Validate the metadata in xsk_tx_metadata_request() and use the resulting flags snapshot for every feature check. Read request fields once so all zero-copy drivers process only values observed after successful validation. Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Cc: Cen Zhang (Microsoft) Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260727161959.885642-7-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a1534cc3b41986c9a41b87c8546b937f07adbb4 Author: Stanislav Fomichev Date: Mon Jul 27 09:19:58 2026 -0700 xsk: move xsk_tx_metadata_request() to xdp_sock_drv.h [ Upstream commit ddd0d6c5bfe2fef7c7cf31f62265f29b7b9eb9ef ] xsk_tx_metadata_request() must validate metadata with xsk_buff_valid_tx_metadata(), which is defined in xdp_sock_drv.h. Move the helper there before adding that dependency. All callers already include the destination header, so this has no functional effect. Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Cc: Cen Zhang (Microsoft) Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260727161959.885642-6-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit af511afa1d2977f384044df78d6fbf9fba653f7a Author: Stanislav Fomichev Date: Mon Jul 27 09:19:57 2026 -0700 xsk: validate launch-time metadata size [ Upstream commit 439ce2dddf3d22129b9113a7881637256a35e936 ] Launch-time metadata extends beyond the first 16 bytes of struct xsk_tx_metadata. Reject the request when the registered metadata area does not contain the complete field. Snapshot the validated flags for the generic transmit path and use that snapshot for request and completion processing, avoiding inconsistent decisions if user space changes the flags concurrently. Note that only xsk_skb_metadata is properly using the flags, __xsk_buff_get_metadata ignores them. Next commits address that. Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Cc: Cen Zhang (Microsoft) Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260727161959.885642-5-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ba2e1eb07a826d021344e2f146b6716c58139eb Author: Stanislav Fomichev Date: Mon Jul 27 09:19:56 2026 -0700 xsk: clear metadata pointer when no timestamp is requested [ Upstream commit 9f60a67df8d3c862503bee62bada8e7089cba438 ] User space can change metadata flags after request processing. Rereading them during completion can therefore make the kernel write a timestamp that was not requested when the packet was submitted. Clear the metadata pointer during request processing unless timestamp completion is requested. Completion handling can then use the pointer itself instead of rereading the flags. On the mlx5 multi-packet WQE path metadata is evaluated per batch: xsk_tx_metadata_request() runs only for the descriptor that starts a session, just like the checksum offload that is applied once through the shared WQE. Only that descriptor's pointer is reset, so completion handling can record a timestamp for the other descriptors of the session regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays inside the metadata area; the single-WQE, other zero-copy, and generic paths reset the pointer per descriptor and are unaffected. Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Cc: Cen Zhang (Microsoft) Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260727161959.885642-4-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ec4f525373bc58e197e05f97a92d03a845a92f7 Author: Stanislav Fomichev Date: Mon Jul 27 09:19:55 2026 -0700 xsk: pass TX metadata pointer by reference [ Upstream commit 19366db6dfccac9b0867a151678cd7b89fb8fd99 ] Completion handling needs to know whether a timestamp was requested when the metadata was processed. Let xsk_tx_metadata_request() update the caller's metadata pointer so that decision can be carried forward without rereading user-controlled flags. This only changes the interface; behavior remains unchanged. Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Cc: Cen Zhang (Microsoft) Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260727161959.885642-3-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 642c6e73fce17fdca93a5793c4d22359fda866d7 Author: Stanislav Fomichev Date: Mon Jul 27 09:19:54 2026 -0700 xsk: require at least 16 bytes of TX metadata [ Upstream commit 1bb30b181d9f0484e141f8411e15ed906d5c6780 ] AF_XDP accepts a TX metadata length as small as eight bytes, but every supported request needs the flags plus at least one eight-byte request field. Such short metadata also lets the kernel read beyond the registered area. Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve compatibility with applications that do not use launch-time metadata. Fixes: 341ac980eab9 ("xsk: Support tx_metadata_len") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Cen Zhang (Microsoft) Link: https://lore.kernel.org/netdev/20260720155210.34229-1-blbllhy@gmail.com/ Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260727161959.885642-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b0b7202f751bbf0f47cdcde7bc6a174d69727d9a Author: Will Chen Date: Wed Jul 29 15:01:31 2026 -0700 bnxt: fix memory leak in bnxt_queue_mem_alloc error cases [ Upstream commit d1000fd7995e51deec872d154e0a40d82f7a539f ] There is a small memory leak in bnxt_queue_mem_alloc: when bnxt_alloc_rx_agg_bmap() succeeds but bnxt_alloc_one_tpa_info() later fails, the rx_agg_bmap allocated by bnxt_alloc_rx_agg_bmap() is not freed in the fallthrough cleanup cases. Free the rx_agg_bmap in the err_free_rx_agg_ring case and initialize clone->rx_agg_bmap = NULL earlier in the function to allow for safe fallthrough. Fixes: bd649c5cc958 ("bnxt_en: handle tpa_info in queue API implementation") Signed-off-by: Will Chen Reviewed-by: Joe Damato Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260729220132.1256924-1-will.chen.tty@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad9ffc61fafeb698e65743ffd0d5d4965c8b65e7 Author: Pavel Begunkov Date: Mon Oct 13 23:10:32 2025 +0100 eth: bnxt: support qcfg provided rx page size [ Upstream commit f96e1b35779e153be266fd7de50bda0c5553ad21 ] Implement support for qcfg provided rx page sizes. For that, implement the ndo_default_qcfg callback and validate the config on restart. Also, use the current config's value in bnxt_init_ring_struct to retain the correct size across resets. Signed-off-by: Pavel Begunkov Stable-dep-of: d1000fd7995e ("bnxt: fix memory leak in bnxt_queue_mem_alloc error cases") Signed-off-by: Sasha Levin commit cd5485a702efdf574a6f08c11d7af23bcad2b822 Author: Pavel Begunkov Date: Mon Apr 21 15:28:11 2025 -0700 eth: bnxt: store rx buffer size per queue [ Upstream commit f57efb32aae1da5c0a25acf473ef4ab559894adf ] Instead of using a constant buffer length, allow configuring the size for each queue separately. There is no way to change the length yet, and it'll be passed from memory providers in a later patch. Suggested-by: Jakub Kicinski Signed-off-by: Pavel Begunkov Stable-dep-of: d1000fd7995e ("bnxt: fix memory leak in bnxt_queue_mem_alloc error cases") Signed-off-by: Sasha Levin commit 9c1406e2ecd2e25a0249ca0fb546aa0037f093d8 Author: Pavel Begunkov Date: Tue Jan 6 13:25:40 2026 +0000 net: pass queue rx page size from memory provider [ Upstream commit c0b709bf438ba9d197d369f55e4a97603fd4a705 ] Allow memory providers to configure rx queues with a custom receive page size. It's passed in struct pp_memory_provider_params, which is copied into the queue, so it's preserved across queue restarts. Then, it's propagated to the driver in a new queue config parameter. Drivers should explicitly opt into using it by setting QCFG_RX_PAGE_SIZE, in which case they should implement ndo_default_qcfg, validate the size on queue restart and honour the current config in case of a reset. Signed-off-by: Pavel Begunkov Stable-dep-of: d1000fd7995e ("bnxt: fix memory leak in bnxt_queue_mem_alloc error cases") Signed-off-by: Sasha Levin commit b3fecb888e94b012270b87751ae02569d326db31 Author: Pavel Begunkov Date: Tue Jan 6 13:25:40 2026 +0000 net: add bare bone queue configs [ Upstream commit efcb9a4d32d3d9b924642c086b868bfbb9a07c13 ] We'll need to pass extra parameters when allocating a queue for memory providers. Define a new structure for queue configurations, and pass it to qapi callbacks. It's empty for now, actual parameters will be added in following patches. Configurations should persist across resets, and for that they're default-initialised on device registration and stored in struct netdev_rx_queue. We also add a new qapi callback for defaulting a given config. It must be implemented if a driver wants to use queue configs and is optional otherwise. Suggested-by: Jakub Kicinski Signed-off-by: Pavel Begunkov Stable-dep-of: d1000fd7995e ("bnxt: fix memory leak in bnxt_queue_mem_alloc error cases") Signed-off-by: Sasha Levin commit 96197286b0ac8dd5f4a5ebff32af200a0bc9511a Author: Jakub Kicinski Date: Mon Apr 21 15:28:15 2025 -0700 net: reduce indent of struct netdev_queue_mgmt_ops members [ Upstream commit 92d76cf96dcbc3c58daa84dbbf71a3ca8d9de53d ] Trivial change, reduce the indent. I think the original is copied from real NDOs. It's unnecessarily deep, makes passing struct args problematic. Signed-off-by: Jakub Kicinski Reviewed-by: Mina Almasry Signed-off-by: Pavel Begunkov Stable-dep-of: d1000fd7995e ("bnxt: fix memory leak in bnxt_queue_mem_alloc error cases") Signed-off-by: Sasha Levin commit 34debe05685d16697757d9b04fb1cde25e8eb1fa Author: Michael Chan Date: Wed Nov 26 13:56:46 2025 -0800 bnxt_en: Do not set EOP on RX AGG BDs on 5760X chips [ Upstream commit 30f253f8d9a01d532fdb7ec6c8a9d4c15fe29241 ] With End-of-Packet padding (EOP) set, the chip will disable Relaxed Ordering (RO) of TPA data packets. A TPA segment with EOP set will be padded to the next cache boundary and can potentially overwrite the beginning bytes of the next TPA segment when RO is enabled on 5760X. To prevent that, the chip disables RO for TPA when EOP is set. To take advantge of RO and higher performance, do not set EOP on 5760X chips when TPA is enabled. Define a proper RX_BD_FLAGS_AGG_EOP constant to make it clear that we are setting EOP. Reviewed-by: Andy Gospodarek Reviewed-by: Somnath Kotur Signed-off-by: Michael Chan Link: https://patch.msgid.link/20251126215648.1885936-6-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: d1000fd7995e ("bnxt: fix memory leak in bnxt_queue_mem_alloc error cases") Signed-off-by: Sasha Levin commit 5ba1a458c5e2666acae50237fd517e7c687ba5bd Author: Nathan Gao Date: Fri Jul 24 20:08:06 2026 -0700 tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss() [ Upstream commit 0e125ecfe20c077625cf0be8d750d5c3abc0dce9 ] Commit f5da7c45188e ("tcp: adjust rcvq_space after updating scaling ratio") replaced the direct window_clamp update in tcp_measure_rcv_mss() with a call to tcp_set_window_clamp(), a helper that implements the TCP_WINDOW_CLAMP setsockopt. As a side effect, the helper also shrinks rcv_ssthresh via __tcp_adjust_rcv_ssthresh(). As a result, each scaling_ratio decrease detected by tcp_measure_rcv_mss() also cuts rcv_ssthresh. Elsewhere in TCP, rcv_ssthresh is usually cut under memory pressure and grows via tcp_grow_window(). Flows whose segment sizes vary keep scaling_ratio oscillating, which leads to an unstable rcv_ssthresh: a dip of rcv_ssthresh only recovers via tcp_grow_window(), keeping the advertised window at a relatively low level even after the ratio itself has recovered, and can even stall the sender. Observed on a customer's proxy gateway after upgrading from kernel 6.1 to 6.12: in the worst case, rcv_ssthresh was cut in half by a scaling_ratio dip. P99 latency jumped from <10ms on 6.1 to ~100ms on 6.12, and almost returned to the 6.1 level with this patch applied. Restore the plain WRITE_ONCE() update of window_clamp, as introduced in commit a2cbb1603943 ("tcp: Update window clamping condition"), and keep the rcvq_space.space adjustment. Now rcv_ssthresh is decoupled from scaling_ratio changes in tcp_measure_rcv_mss(). Fixes: f5da7c45188e ("tcp: adjust rcvq_space after updating scaling ratio") Signed-off-by: Nathan Gao Link: https://patch.msgid.link/20260725030806.28135-1-zcgao@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 821f6416e69782fa662aff94b5ea52c943042790 Author: Guenter Roeck Date: Thu Jul 23 10:57:35 2026 -0700 hwmon: (pmbus) Fix type confusion in notification logic [ Upstream commit 59bd68ab05a8f9c9a60b6ec44682084184803ff4 ] Sashiko reports: At the start of the loop in pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmbus_sensor, which only embed a base struct device_attribute. If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting it to struct sensor_device_attribute and reading the index field appears to access memory past the end of the allocation, which might trigger a slab-out-of-bounds read. Additionally, if da is a struct pmbus_sensor, casting it causes the index field to overlap with the page, phase, and reg fields. Could this produce a garbage mask on little-endian systems that spuriously matches the target reg, page, and flags during an alert? Fix the problem by using struct sensor_device_attr in struct pmbus_sensor and struct pmbus_label. Since those attributes never trigger a notification, set the value of attr->index to -1 for them. Use this value to distinguish from boolean attributes which _can_ trigger a notification and use the index field to encode mask, page, and register values. Fixes: f469bde9afd1 ("hwmon: (pmbus/core) Notify hwmon events") Cc: Vincent Jardin Tested-by: Vincent Jardin Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 11720d869be1a95403d117621967221f6bf6ed09 Author: Guenter Roeck Date: Fri Mar 20 07:45:55 2026 -0700 hwmon: (pmbus_core) Use guard() for mutex protection [ Upstream commit bd1c178affd7d1ca86eaf97cf797e0d15e57eb0a ] Simplify the code by using guard() and scoped_guard() instead of mutex_lock()/mutex_unlock() sequences. This patch changes semantics for debugfs accesses. Previously, those used mutex_lock_interruptible() and not mutex_lock(). This change is intentional and should have little if any impact since locks should not be held for a significant amount of time and debugfs accesses are less critical than sysfs accesses (which never used interruptable locks). Reviewed-by: Sanman Pradhan Signed-off-by: Guenter Roeck Stable-dep-of: 59bd68ab05a8 ("hwmon: (pmbus) Fix type confusion in notification logic") Signed-off-by: Sasha Levin commit cde8931a25392670dd59a0acfcab87a830ab66c5 Author: Christian Borntraeger Date: Mon Jul 6 16:15:37 2026 +0200 vdpa/mlx5: Fix buffer length in create_direct_keys() [ Upstream commit 727e1f569855df83579edbd73dcb4a0723543a12 ] We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size. Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel") Signed-off-by: Christian Borntraeger Tested-by: Dragos Tatulea Reviewed-by: Dragos Tatulea Signed-off-by: Michael S. Tsirkin Message-ID: <20260706141537.3510294-1-borntraeger@linux.ibm.com> Signed-off-by: Sasha Levin commit a1c236b385d85b9cdd6f2aed7d31ec49f623e911 Author: Yousef Alhouseen Date: Wed Jun 24 15:02:02 2026 -0700 vhost/vdpa: reject overflowing PA map page counts on 32-bit [ Upstream commit 0619aaa34c0c2a2dcb07f0e9c8a34e7efb8c4cdf ] vhost_vdpa_pa_map() adds the IOVA page offset to the user-controlled map size before computing the number of pages to pin. On 32-bit systems, where unsigned long is narrower than u64, that addition can overflow and the code can pin and map fewer pages than the requested IOTLB range. Reject sizes that overflow the unsigned long page-count calculation. Fixes: 22af48cf91aa ("vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap()") Acked-by: Michael S. Tsirkin Signed-off-by: Yousef Alhouseen Signed-off-by: Michael S. Tsirkin Message-ID: Signed-off-by: Sasha Levin commit cefcbbe20846a45f9a7dae868f7ef1000953e2df Author: Jose Fernandez (Anthropic) Date: Thu Jul 30 22:32:47 2026 +0000 bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() [ Upstream commit e5fd3f514e27db1f05fbd72ba615d74941e23c51 ] reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcount_set() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so end_sk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an end_sk == expected check that could not hold on that path since commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always contains a full bucket snapshot"). If every matching socket in a bucket is mid-init (refcount 0), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round. Fixes: 04c7820b776f ("bpf: tcp: Bpf iter batching and lock_sock") Assisted-by: Claude:unspecified Signed-off-by: Jose Fernandez (Anthropic) Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/bpf/20260730-bpf-iter-tcp-refcnt-v3-1-754b9c8a6717@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 846ce792b6dd2188e761a1140058e2753c3a7e81 Author: Babanpreet Singh Date: Tue Jul 14 04:29:10 2026 +0000 counter: microchip-tcb-capture: Fix DT channel validation [ Upstream commit f1a3a9946aab611dd2200c01ff122f64b033dad2 ] mchp_tc_probe() reads the devicetree "reg" cell - a u32, per the API contract of of_property_read_u32_index() - into a signed int, so the bounds check "channel > 2" fails to reject cell values at or above 0x80000000: reinterpreted as a negative int, they compare below 2 and pass validation. A malformed devicetree can therefore drive a negative channel into the ATMEL_TC_REG() offset arithmetic, making the driver access syscon regmap offsets outside the TC block's register window, and into the "t%d_clk" clock-name formatting, where it truncates clk_name (sized for "t0_clk".."t2_clk"). Declare channel as u32, matching the API contract; the unsigned comparison then rejects everything except channels 0..2. Adjust the format specifier to %u accordingly, which also resolves the W=1 warning that exposed the gap: microchip-tcb-capture.c:520:56: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] note: directive argument in the range [-2147483648, 2] No behavior change for well-formed devicetrees: channels 0..2 take identical paths before and after. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Assisted-by: Claude:claude-fable-5 [gcc W=1] Signed-off-by: Babanpreet Singh Reviewed-by: Joshua Crofts Link: https://lore.kernel.org/r/20260714042910.7-1-bbnpreetsingh@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin commit 80094352bd40ba54a33731f9c22872493983ed6d Author: Michael Guralnik Date: Wed Jul 29 11:04:02 2026 +0300 net/mlx5: fw_tracer, return NULL on create error [ Upstream commit af39eb111ce6b5eba9c08513b62c4868eb7e7fd5 ] Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P) mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]--- Fixes: fd1483fe1f9f ("net/mlx5: Add support for FW reporter dump") Signed-off-by: Michael Guralnik Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260729080402.2427184-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7b02c6d2a3cd2cd669f5c16685779f84328ae60c Author: Or Har-Toov Date: Wed Jul 29 11:06:00 2026 +0300 devlink: fix net namespace reference leak in reload [ Upstream commit 1c4dac9bf1d2ac31da63b794bdec697777cbd0fd ] devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path. Fixes: 2edd92570441 ("devlink: don't allow to change net namespace for FW_ACTIVATE reload action") Signed-off-by: Or Har-Toov Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Reviewed-by: Antoine Tenart Link: https://patch.msgid.link/20260729080600.2427721-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1efcc71140094aa23d77656a7bac3be649058d02 Author: Jiawen Liu <1298662399@qq.com> Date: Tue Jul 28 12:17:10 2026 +0400 net: hisilicon: hix5hd2_gmac: remove redundant NAPI delete [ Upstream commit f307a7dc32097c11413178fca437a10d20890bc2 ] hix5hd2_dev_remove() calls netif_napi_del() before unregister_netdev(). This is not needed because free_netdev() deletes all NAPI instances attached to the net_device. Remove the redundant call and let the networking core tear down the NAPI instance during unregister_netdev(). The probe error path still keeps its explicit netif_napi_del(), because the device has not been registered there. Fixes: 57c5bc9ad7d7 ("net: hisilicon: add hix5hd2 mac driver") Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_5FFD37A252B4FEA6A80AD25B17C8E904F005@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0e7a8cf8895b06d07c7311f028eba16ad742b9bc Author: Jamal Hadi Salim Date: Wed Jul 29 05:44:11 2026 -0400 net/sched: cls_route: fix fastmap use-after-free on filter [ Upstream commit 47d7f7051253bdc02b1d245d87e38f16d31a74df ] The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter. This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths. Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers. Fixes: 1109c00547fc ("net: sched: RCU cls_route") Reported-by: zdi-disclosures@trendmicro.com Reported-by: Santosh Kalluri Suggested-by: Paolo Abeni Tested-by: Victor Nogueira Tested-by: Santosh Kalluri Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260729094411.46257-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 10cb31b2b74cb664c6c95cf72364d7d5c483ab82 Author: Mahanta Jambigi Date: Wed Jul 29 15:01:53 2026 +0200 net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() [ Upstream commit 976245094925bab9bc39366b2e9ab44ffcde61d0 ] The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly. Fixes: 0fb0b02bd6fd ("net/smc: adapt SMC client code to use the LLC flow") Signed-off-by: Mahanta Jambigi Reviewed-by: Hidayath Khan Reviewed-by: Sidraya Jayagond Reviewed-by: Dust Li Link: https://patch.msgid.link/20260729130153.970800-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8a6f7993520573ca1d644d19d7e7d55820a86f3 Author: Yiyang Chen Date: Wed Jul 29 15:18:29 2026 +0000 bpf: Propagate untrusted pointer state in commuted arithmetic [ Upstream commit cdf19b1b3c01791de074ce282089131026f52261 ] The untrusted PTR_TO_MEM early return skips pointer offset tracking because accesses go through probe-read handling. Moving it after full pointer-state propagation ensures scalar += untrusted_pointer leaves the destination as PTR_TO_MEM instead of an unrelated scalar. Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()") Signed-off-by: Yiyang Chen Tested-by: Daniel Wade Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-3-8ee297e2346b@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit c2da73a1f715f2565a68f265a253ca4c9b711ee6 Author: Eduard Zingerman Date: Thu Feb 12 13:34:21 2026 -0800 bpf: split check_reg_sane_offset() in two parts [ Upstream commit ed20a14309e09216d1fa86e12b1578fa822119b4 ] check_reg_sane_offset() is used when verifying operations like: dst_reg += src_reg ^ ^ | '-------- scalar '------------------- pointer To verify range for both dst_reg and src_reg. Split it in two parts: - one to check a pointer offset - another to check scalar offset This would be useful for further refactoring. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260212-ptrs-off-migration-v2-1-00820e4d3438@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: cdf19b1b3c01 ("bpf: Propagate untrusted pointer state in commuted arithmetic") Signed-off-by: Sasha Levin commit db6382ed3361bdd8129572a3423956cba1dae829 Author: Yiyang Chen Date: Wed Jul 29 15:18:28 2026 +0000 bpf: Preserve pointer state for commuted arithmetic [ Upstream commit a4c6f804b44c5c790269b25e0e61cf4e9f117c86 ] When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent. Fixes: f4d7e40a5b71 ("bpf: introduce function calls (verification)") Signed-off-by: Yiyang Chen Tested-by: Daniel Wade Acked-by: Shung-Hsi Yu Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-2-8ee297e2346b@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 24a8f2c29aebb753ccb962fbb25bae18d7978f6e Author: Dmitry Antipov Date: Mon Jul 27 14:53:52 2026 +0300 btrfs: fix memory leak in btrfs_do_encoded_write() [ Upstream commit d2a4e4e626b2f4670b69b430c357f03f53eb6632 ] Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write(). Fixes: 7c0c7269f7b5 ("btrfs: add BTRFS_IOC_ENCODED_WRITE") Reviewed-by: Filipe Manana Signed-off-by: Dmitry Antipov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 26e968526eb534a9535432b83550c411eddb52ca Author: Matti Vaittinen Date: Fri Jul 31 12:36:28 2026 +0300 watchdog: bd96801_wdt: Fix timeout for enabled WDG [ Upstream commit 1246aa2b6ccc8944676bd24ff3e37cc56b93b51b ] When watchdog is enabled at the probe time, the bd96801 driver retrieves the timeout configuration from the registers to set-up the heart-beat values. As Sashiko pointed out at https://lore.kernel.org/all/20260722085819.495211F000E9@smtp.kernel.org/ the timeout values are incorrectly computed in driver, resulting wrong heartbeat. This leads to devere problems if watchdog was enabled at probe time. According to the data-sheet, the "too fast" ping limit is configured as multiple of FASTNG_MIN. Furthermore, the "too slow" ping limit is configured as multiples of "too fast" timeout. The FASTNG_MIN is set to 11, meaning 1.1 mS and "too fast" and "too slow" limits are computed from this. Hence, converting the limits to mS should be done by dividing by 10, not by dividing by USEC_PER_MSEC. Fix this by dividing the timeout values with correct scaling factor. While at it, fix whitespace problem (double empty line). Signed-off-by: Matti Vaittinen Fixes: 09dad69757b6 ("watchdog: ROHM BD96801 PMIC WDG driver") Link: https://lore.kernel.org/r/amxskHmQbi9v-8_l@mva-rohm [groeck: Added reference to whitespace change to description] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b3ff48c4ea8b2ebfef70c6132c0992f87e4c8126 Author: Julian Anastasov Date: Thu Jul 30 21:35:06 2026 +0300 ipvs: return the csum validation for forward hook [ Upstream commit 99609cb0aa789c8d071050ce8579989551882cc6 ] Sashiko notes that playing games with the skb dst and rt flags instead of providing hooknum is not a good idea when validating the checksums. Also, skipping checksum validation for FORWARD packets risk silent data corruption, even if the only user is the FTP-CMD packets coming from the real server. Sashiko also noticed that by using common checksum helper in the previous commit we actually fixed old bug where the TCP/UDP checksum for IPv6 on CHECKSUM_COMPLETE was not validated correctly. Fixes: e876b75b9020 ("ipvs: fix the checksum validations") Link: https://sashiko.dev/#/patchset/20260722211420.153933-1-pablo%40netfilter.org Link: https://sashiko.dev/#/patchset/20260727185024.67534-1-ja%40ssi.bg Link: https://sashiko.dev/#/patchset/20260728202520.59179-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a69a4b3fff5814d079beff9a1e9d369994b2ed47 Author: Julian Anastasov Date: Thu Jul 30 21:35:05 2026 +0300 ipvs: avoid out-of-bounds write in ip_vs_nat_icmp [ Upstream commit 646922a0379496154e8c8faca4f8e2fd9100cacc ] Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area. Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header. Modify some IPv4 header checks by reading the ihl field only once. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260722101517.36313-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1e8a5467a7a7bc86723db527ca5bf839e70b2134 Author: Jozsef Kadlecsik Date: Thu Jul 30 20:38:50 2026 +0200 netfilter: ipset: switch ext_size to atomic64_t [ Upstream commit 712a6f545c359b427daa9a5a782e30d2f8331e25 ] The hash types do not acquire set->lock, they use 'region locking' where only part of the hash table is locked. Parallel inserts and deletes are possible and CPUs can race on ->ext_size update. Switch to atomic64_t. This leaves another bug unresolved: there still can be a race on comment extension re-init. This will be handled in a later commit when converting to rhashtable backend. Fixes: f66ee0410b1c ("netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports") Signed-off-by: Jozsef Kadlecsik Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 970e9494f44afce3ca93cdc6e0ce85fa9037693f Author: Nikhil P. Rao Date: Mon Jul 27 17:00:30 2026 +0000 pds_core: cancel pending PCI reset work on AER recovery [ Upstream commit 57d635329d799b79096155cdf47ee0013d6780d1 ] pdsc_check_pci_health() queues pci_reset_work when it sees a broken PCI connection, and nothing cancels it. When the PCI core starts AER recovery, pdsc_pci_error_detected() runs pdsc_reset_prepare() and recovers the device, but a pci_reset_work queued just before is left pending. If it runs after recovery released the device lock, it resets a device the driver now considers healthy, bouncing the link for no reason. Cancel pci_reset_work in pdsc_pci_error_detected() after pdsc_reset_prepare(), which has already stopped the health thread so it cannot requeue the work. cancel_work_sync() is safe under the device lock here because pdsc_pci_reset_thread() uses pci_try_reset_function(), which returns instead of blocking on the lock. Only PFs initialize pci_reset_work, so guard the cancel with !is_virtfn. Fixes: 81665adf25d2 ("pds_core: Fix pdsc_check_pci_health function to use work thread") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260714180223.1642792-2-nikhil.rao%40amd.com?part=1 Signed-off-by: Nikhil P. Rao Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260727170030.361116-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef8e37ac448d47ca4fe0f756af8bef89a8cdfb52 Author: Nikhil P. Rao Date: Mon Jul 27 16:45:48 2026 +0000 pds_core: keep the health thread stopped during reset [ Upstream commit cd09971dcc1c499ae0879010a00e9dba87abdc4f ] Commit d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove") stops the health thread with cancel_work_sync() before a reset, but a devcmd timeout during pdsc_fw_down() re-queues health_work, so pdsc_health_thread() runs again mid-reset and double allocates the core DMA queues via pdsc_fw_up(). Only the reset path is affected: on remove PDSC_S_STOPPING_DRIVER gates the health thread and the workqueue is destroyed. Use disable_work_sync() to cancel health_work and block further queue_work() on it, and enable_work() in pdsc_restart_health_thread() to re-allow it after the reset. disable_work_sync() keeps a disable depth, so every disable must be matched by one enable. pdsc_reset_prepare() stops the health thread and pdsc_reset_done() restarts it. On the AER path pdsc_pci_error_detected() calls pdsc_reset_prepare(), then pdsc_pci_error_resume() re-inits via pci_reset_function_locked() (pds_core has no .slot_reset handler), which runs the pair again - stopping the thread twice but restarting it once. Gate the disable and enable on a health_stopped flag so each fires at most once per stopped/running transition. Fixes: d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260727164548.359562-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff9e7d5e3500be389ce7a0e46db3a77149830bc9 Author: Shay Drory Date: Tue Jul 28 07:43:38 2026 +0300 net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock [ Upstream commit 6ddfba2ea98db21b001e0e5c472499156224650c ] In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows") Signed-off-by: Shay Drory Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260728044338.2271143-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e506e704b74748ffd0e1c92a7453ca2a959f832b Author: Satish Kharat Date: Mon Jul 27 23:26:30 2026 -0700 enic: fix tx_hang_reset use-after-free on device removal [ Upstream commit ec680ea4ba1bca92a767fb7e7869758bfdd886e3 ] enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work. Fixes: 937317c7c109 ("enic: do hang reset only in case of tx timeout") Signed-off-by: Satish Kharat Link: https://patch.msgid.link/20260728062730.2394873-1-satishkh@cisco.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2faf75a8a06504071b4c0aea7e45a9cc49a4e187 Author: Xiang Mei (Microsoft) Date: Sat Jul 25 23:39:30 2026 +0000 bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor [ Upstream commit 683c6ba6e58e6ed1037831ea97dd58d9c0e76b8d ] bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision. Fixes: d0e81b7e2246 ("bonding: Acquire correct locks in alb for promisc change") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260725233930.2957317-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35ddcc856b5b3f428e0d5db235ec78249a380893 Author: Fan Ye Date: Mon Jul 27 12:29:48 2026 +0000 Revert "net: thunderbolt: Enable end-to-end flow control also in transmit" [ Upstream commit 1881f2efbf7f78dc0a79a387b29fde6ff56d3731 ] This reverts commit a8065af3346ebd7c76ebc113451fb3ba94cf7769. Per the USB4 spec, a Transmit Descriptor Ring with E2E flow control disabled does not require any credits to be available before the Host Interface Adapter Layer transmits a tunneled packet from it. Once E2E is enabled on that ring the controller must first obtain end-to-end credits. The ASMedia ASM4242 USB4 host router (PCI 1b21:2425) never delivers those credits. The controller does accept the configuration: reading the ring OPTIONS register back right after tb_ring_start() returns exactly what was written, including RING_FLAG_E2E_FLOW_CONTROL (bit 28) and the E2E HopID field. No credit ever arrives though, so the Tx ring's hardware consumer index never advances and the link carries no traffic at all. Measured on two hosts connected point to point, onboard ASM4242 on MSI X870E and X870, v6.17, stock drivers/net/thunderbolt/main.c with only this revert applied on top: before: 100% packet loss to the peer; thunderbolt0 is up and the XDomain handshake completes ("new host found"), but iperf3 fails with "No route to host" once the neighbour entry expires after: 0% packet loss, 0.28 ms RTT; iperf3 4.21 Gb/s one way and 5.17 Gb/s the other (5 runs each, stddev <= 0.02), 1 retransmit in 10 s An instrumented build additionally showed a frozen-Tx-consumer watchdog firing ~30k times in a 10 s window before this change. Rx-side E2E is not touched by this revert, so peers that do return credits keep receive-side flow control. ASMedia does not look like an isolated case. The out-of-tree thunderbolt-ibverbs project disables native E2E on AMD NHI by default, noting that "Strix Halo has reproduced TX completion wedges with multiple native E2E rings active" -- the same failure mode, on a different vendor. Since the driver has no way to tell in advance which host router returns the credits, going back to the previous behaviour looks safer than adding a quirk per affected part; Tx-side E2E can be reintroduced as an opt-in for controllers that are known to implement the credit return. Note that the reverted commit was not fixing a reported problem, it was derived from the spec wording alone, so this revert is not expected to regress a known workload. Cc'ing the original author in case there was one. Fixes: a8065af3346e ("net: thunderbolt: Enable end-to-end flow control also in transmit") Cc: zhangjianrong Signed-off-by: Fan Ye Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260727123002.25225-1-fy15309206903@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d512823059af83d8536865a0118c9ba25dee92d4 Author: Jijie Shao Date: Fri Jul 24 17:30:36 2026 +0800 net: hns3: fix speed configuration residue after driver reload [ Upstream commit 3860d8748af315bfee6fe669fddc1fc17d3214db ] After setting a 100G optical port to 40G via ethtool and reloading the driver, the port remains at 40G instead of reverting to the firmware default speed of 100G. The commit referenced in Fixes: added two overwrites in hclge_init_ae_dev() for non-copper media, so that optical ports connected to forced-mode remotes inherit the firmware-preset autoneg and speed instead of the hardcoded defaults: req_autoneg = mac.autoneg req_speed = mac.speed (when autoneg disabled) The autoneg overwrite keeps existing behavior: hclge_set_autoneg_speed_dup() already uses mac.autoneg (not req_autoneg) since it was introduced, so autoneg inheritance from firmware was already in place. This part is kept. The speed overwrite, however, introduces the residue: mac.speed reflects whatever was last programmed into the MAC, and after unload firmware does not restore the MAC speed to the flash default. So if the user changed speed via ethtool in a prior load, mac.speed still carries that value on reload and req_speed inherits it. Fix by dropping the req_speed overwrite only. req_speed keeps the firmware default value set in hclge_configure() (cfg.default_speed), so a reload reverts the speed to default, matching the expectation that a driver reload resets link configuration. Trade-off: on optical ports whose firmware default speed does not match a forced-mode remote, reload now drops the link and the user must re-apply ethtool configuration. This is acceptable: a driver reload is expected to reset link configuration, not to inherit runtime state from before unload. The autoneg inheritance is left in place as established behavior; changing it is out of scope for this patch and would itself be a user-perceivable behavior change. Fixes: d9d349c4e8a0 ("net: hns3: differentiate autoneg default values between copper and fiber") Signed-off-by: Jijie Shao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260724093036.426631-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8701a643db2313bcaa72569accd758d751de40de Author: Pengpeng Hou Date: Thu Jul 23 10:38:06 2026 +0800 drm/bridge: ps8640: propagate AUX transfer register errors [ Upstream commit 20697ecb299cd77b4cf8b28f655e56606b0472d8 ] ps8640_aux_transfer_msg() programs the AUX address registers, starts the AUX transfer, waits for SWAUX_SEND to clear, and reads the AUX status register. Several of those regmap operations have return values, but the function only checks a stale ret after the status read. Propagate failures from the address write, transfer start, completion poll, and status read. This avoids returning a transfer length when the bridge register transaction or AUX completion wait failed. Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") Signed-off-by: Pengpeng Hou Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260723103509.2-ps8640-v2-pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit d47212d8669068490bbf6d6f1814233f06cf72f8 Author: Qingfang Deng Date: Fri Jul 24 09:49:26 2026 +0800 ovpn: fix incorrect use of rcu_access_pointer() [ Upstream commit 26ba17d845193dac4921ae1ab280d28d1938052e ] rcu_access_pointer() should only be used to test the value of a pointer, not to dereference it. As it's in a spin_lock_bh() critical section, use rcu_dereference_bh() instead, avoiding an extra rcu_read_lock(). Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Qingfang Deng Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 54dd83f24b913a224db96d1ee6e1e76004b97978 Author: Antonio Quartulli Date: Tue Jul 28 13:48:54 2026 +0200 ovpn: ensure TCP vars are initialized first [ Upstream commit 4680c0ebd958fc18e53c8b91d80436b236a8fc09 ] Netlink calls may access TCP global vars (i.e. when attaching a TCP socket), therefore we need to make sure the latters are initialized beforehand. For this reason move the global TCP initialization at the top of the module init function. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit f34949d63cbbeb76d7351f2a6ec9b2061785f5f2 Author: Antonio Quartulli Date: Tue Jul 28 13:48:53 2026 +0200 ovpn: disable IPv4 redirects on MP interfaces [ Upstream commit 0301aa324941698bec3dd455df1c5abc7afb10db ] ovpn_mp_alloc() tried to disable SEND_REDIRECTS on a multipeer interface, but it runs from ovpn_net_init() (->ndo_init), which register_netdevice() invokes before the NETDEV_REGISTER notifier chain. The IPv4 in_device is only created when that notifier reaches inetdev_event() -> inetdev_init(), so __in_dev_get_rtnl() always returned NULL at ndo_init time and the whole redirect-disabling block (both the per-device and the per-netns IPV4_DEVCONF_ALL write) was dead. MP interfaces therefore kept emitting ICMP redirects. Disabling redirects only once is not enough either: the IPv4 in_device is destroyed and recreated when the interface is moved to a different network namespace (NETDEV_UNREGISTER/NETDEV_REGISTER), and the newly created in_device inherits the destination namespace defaults, silently re-enabling SEND_REDIRECTS. Disable redirects from ovpn_net_open() (->ndo_open) instead: it runs every time the interface is brought up, including after the in_device has been recreated, so the setting is always re-applied. This mirrors what wireguard does in wg_open(). RTNL is held on the ndo_open() path, so __in_dev_get_rtnl() is safe. Fixes: 05003b408c20 ("ovpn: implement multi-peer support") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit e774f7d8fc733b8159b55647fe086447dc4e4544 Author: Antonio Quartulli Date: Tue Jul 28 13:48:52 2026 +0200 ovpn: hash floated peer by transport identity only [ Upstream commit b47a52dcd598a50207a33df304acdf45348a690f ] The by_transp_addr table is keyed on the peer's remote transport address, but the float rehash hashed bind->remote directly, while the two other sites that touch the table build a clean key first: ovpn_peer_add_mp() and the lookup in ovpn_peer_get_by_transp_addr() both hash a sockaddr holding only family/address/port. For a link-local IPv6 peer, bind->remote carries sin6_scope_id (set from ipv6_iface_scope_id() when the endpoint is learned), and that field is folded into the jhash() over sizeof(struct sockaddr_in6). The lookup never sets sin6_scope_id, so after such a peer floats it is rehashed into a scope_id-dependent bucket that lookups (scope_id 0) never visit, making the peer unreachable through the by_transp_addr fallback. ovpn_peer_transp_match() only compares address and port, so the hash was keying on a field the match ignores. sin6_scope_id must stay in bind->remote because the TX path uses it as flowi6_oif, so it cannot just be cleared there. Instead build the hash key from family/address/port only, exactly like ovpn_peer_add_mp() and the lookup, so all three sites agree on the bucket. Fixes: f0281c1d3732 ("ovpn: add support for updating local or remote UDP endpoint") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 9a776388ef8d55b2493a740214358bdbbfe81ba7 Author: Antonio Quartulli Date: Tue Jul 28 13:48:51 2026 +0200 ovpn: zero-initialize sockaddr before learning a floated endpoint [ Upstream commit 3f012bdbabe211ccbc0c50ea5a1dbc60f8af1532 ] ovpn_peer_endpoints_update() builds the new remote endpoint in an on-stack struct sockaddr_storage that is left uninitialized. For IPv4 only sin_family/sin_addr/sin_port are written, leaving the 8-byte sin_zero padding as stack garbage (for IPv6, sin6_flowinfo is left uninitialized likewise). ovpn_peer_reset_sockaddr() -> ovpn_bind_from_sockaddr() then memcpy()s sizeof(struct sockaddr_in)/sizeof(struct sockaddr_in6) bytes - padding included - into bind->remote. That buffer is later hashed with jhash() over the same length to place the peer in the by_transp_addr table, so the garbage padding lands the floated peer in an essentially random bucket. Lockless lookups in ovpn_peer_get_by_transp_addr() build their key from a zero-initialized sockaddr_storage, compute a different bucket and fail to find the peer. This is also a plain use of uninitialized stack memory in jhash(). Build the floated endpoint with a designated initializer so the padding (sin_zero for IPv4, sin6_flowinfo for IPv6) is zeroed as part of the assignment. This keeps the padding out of the by_transp_addr hash key without memset-ing the whole sockaddr_storage on every received packet. Fixes: f0281c1d3732 ("ovpn: add support for updating local or remote UDP endpoint") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 61fb3cca40ff938671474f4a16adb908c19032d7 Author: Antonio Quartulli Date: Tue Jul 28 13:48:50 2026 +0200 ovpn: ensure socket is owned by ovpn before deref sk_user_data [ Upstream commit 59aed1eb60d70678a53acccb0cb337a26ce6680e ] Some subsystems, like BPF SOCKMAP, set sk_user_data without actually setting the encap_type. For this reason, we must make sure that the type is the one ovpn expects before dereferencing sk_user_data. Failing to do so may lead to out-of-bounds reads. Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 157164812a0c529200aeab566b3f0eddba34f99a Author: Antonio Quartulli Date: Tue Jul 28 13:48:48 2026 +0200 ovpn: rehash peer in by_transp_addr table on CMD_PEER_SET [ Upstream commit cc12f7240c8c4dee557749d33237542613992f14 ] When userspace updates a peer's remote endpoint via OVPN_CMD_PEER_SET, ovpn_nl_peer_modify() installs a new ovpn_bind through ovpn_peer_reset_sockaddr(), but ovpn_nl_peer_set_doit() only calls ovpn_peer_hash_vpn_ip() to refresh the VPN-IP hashtables. The peer is left in the bucket of peers->by_transp_addr corresponding to its old remote address. As a consequence, datagrams arriving at the UDP RX path from the newly configured remote hash to a different slot and the lockless lookup in ovpn_peer_get_by_transp_addr() (called from ovpn_udp_encap_recv()) does not find the peer, until either a float event or a peer re-add fixes the bucket. Introduce ovpn_peer_hash_transp_addr() (modeled after ovpn_peer_hash_vpn_ip()) and invoke it from ovpn_nl_peer_set_doit() whenever the request carried a new remote address. The helper bails out in P2P mode and on peers without a bind (TCP), and relies on hlist_nulls_del_init_rcu()'s pprev==NULL short-circuit to handle the case of an entry not currently linked in the table. Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit d20c181088984b6eaa8d7fe7cb5ab3510988df59 Author: Antonio Quartulli Date: Tue Jul 28 13:48:47 2026 +0200 ovpn: skip rehash for peers already removed from by_id [ Upstream commit 33ec10567fe14456063daf549fdf1a4f53448e4c ] ovpn_nl_peer_set_doit() resolves the target peer via ovpn_peer_get_by_id() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spin_lock_bh(&ovpn->lock), a concurrent OVPN_CMD_PEER_DEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpn_peer_remove() to unhash the peer from all four tables (by_id, by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then acquires ovpn->lock and calls ovpn_peer_hash_vpn_ip(), which re-inserts the now-removed peer back into the rehashing tables. The same race affects the float path: ovpn_peer_endpoints_update() holds only a refcount and acquires ovpn->lock very late (after async AEAD decrypt and a netlink notification), then rehashes the peer in the by_transp_addr table. The resurrected peer becomes reachable again from the RX lookup (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though userspace believes it is gone. Once the data-path refcount drops the peer is freed via call_rcu while the hash entries embedded in it remain linked, opening a UAF window. Bail out of the rehash when hash_entry_id is unhashed, mirroring the sentinel already used by ovpn_peer_remove() to detect the already-removed state. The check is safe under ovpn->lock, which serializes every mutation of hash_entry_id, and is a no-op for the add path because ovpn_peer_add_mp() inserts hash_entry_id before calling ovpn_peer_hash_vpn_ip(). Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 9e5e88fbfc87d6a9edf72f8febc94061a6d0395e Author: Rosen Penev Date: Sat Jul 25 14:57:22 2026 -0700 ARM: dts: BCM5301X: fix PCIe controller 2 second interrupt [ Upstream commit bab4d538f8485e0d48538fcb82b285df3779278e ] PCIe controller 2 has interrupts 0-4 mapping to GIC SPI 138-142. The mapping for interrupt 1 was incorrectly set to 138 due to a copy-paste error. Fix it to 139. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Link: https://lore.kernel.org/r/20260725215722.9323-1-rosenp@gmail.com Fixes: 3b3e35b279be ("ARM: dts: BCM5301X: Relicense AXI interrupts code to the GPL 2.0+ / MIT") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 92b9d92a35a0ffc937eef12ef6be7305988f4495 Author: Ralf Lici Date: Wed Jul 29 15:41:30 2026 +0200 ovpn: add missing rtnl_link_ops->get_size callback [ Upstream commit 6e9f539e4f01153651dd77609b5ccadd44b74df8 ] ovpn_fill_info emits IFLA_OVPN_MODE inside IFLA_INFO_DATA, but ovpn_link_ops does not provide a get_size callback. Consequently, rtnetlink's size estimate for ovpn link messages does not include the nested mode attribute. Available skb tailroom may hide this mismatch. When the remaining space is insufficient, however, ovpn_fill_info returns -EMSGSIZE and message construction fails. Add the callback and account for IFLA_OVPN_MODE. Fixes: c2d950c4672a ("ovpn: add basic interface creation/destruction/management routines") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit d740dea9e255700f55e40446cfa236c87b70c92d Author: Hans Ulli Kroll Date: Sun Jul 19 15:36:00 2026 +0200 pinctrl: qcom: ipq806x: mark pci reset as a GPIO pin function [ Upstream commit fd46760956509f580f7d3d25db4de10e7c6f949b ] The qcom pinctrl core supports marking functions that represent GPIO mode via PINCTRL_GPIO_PINFUNCTION(), so that strict pinmuxing does not reject GPIO requests for pins that are muxed to the GPIO function. Mark PCIe reset as GPIO pin function This allows ipq806x to keep the PCIe-reset related configuration in DTS without tripping over strict pinmux ownership checks. Fixes: cc85cb96e2e4 ("pinctrl: qcom: make the pinmuxing strict") Signed-off-by: Hans Ulli Kroll Acked-by: Linus Walleij Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260719134548.8830-3-linux@ulli-kroll.de Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 23c94a468efe30663255d973184f7f89e0a76fb0 Author: Hans Ulli Kroll Date: Sun Jul 19 15:35:59 2026 +0200 pinctrl: qcom: ipq806x: mark gpio as a GPIO pin function [ Upstream commit 687f39faccba29ab26de965411db37e849af8ec2 ] The qcom pinctrl core supports marking functions that represent GPIO mode via PINCTRL_GPIO_PINFUNCTION(), so that strict pinmuxing does not reject GPIO requests for pins that are muxed to the GPIO function. Add a IPQ_GPIO_PIN_FUNCTION() helper and use it for the ipq806x gpio function, matching how the msm-based qcom drivers handle this. This allows ipq806x to keep the GPIO-related configuration in DTS without tripping over strict pinmux ownership checks. Fixes: cc85cb96e2e4 ("pinctrl: qcom: make the pinmuxing strict") Signed-off-by: Hans Ulli Kroll Acked-by: Linus Walleij Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260719134548.8830-2-linux@ulli-kroll.de Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 913d2295b772ef5658c63f9e93135219fb6cebf8 Author: Kuba Piecuch Date: Thu Jul 23 09:59:55 2026 +0000 selftests/sched_ext: Handle sleeping task affinity changes in numa test [ Upstream commit d4a00d61a5c2c24973175ace5368d1f6acf9bb0a ] When a sleeping task's affinity is changed, task_cpu(p) can be outside of p->cpus_ptr until after select_task_rq() selects a new runqueue for the task during wakeup. Thus, the task's NUMA node determined by numa_select_cpu() can be completely outside of the task's cpumask, leading to scx_pick_{idle,any}_cpu_node() failing to find an eligible CPU and returning -EBUSY. This leads to the numa.bpf.c scheduler abnormally exiting with the following message in dmesg: sched_ext: numa: invalid CPU -16 scx_bpf_cpu_node+0x120/0x190 bpf_prog_0a34b8e0f515771f_numa_select_cpu+0x108/0x14e bpf__sched_ext_ops_select_cpu+0x4f/0xb4 select_task_rq_scx+0xb0/0x210 select_task_rq+0xa0/0xd0 __try_to_wake_up+0x196/0x650 complete_all+0x76/0x100 migration_cpu_stop+0x22b/0x300 cpu_stopper_thread+0xc1/0x180 smpboot_thread_fn+0x16b/0x230 kthread+0x2d7/0x350 ret_from_fork+0x1c2/0x350 ret_from_fork_asm+0x1a/0x30 Make numa_select_cpu() robust against this case by returning @prev_cpu if no CPU could be found in the selected NUMA node _and_ we have reason to believe that the task's affinity was changed while it was sleeping. Fixes: 5ae5161820e5 ("selftests/sched_ext: Add NUMA-aware scheduler test") Signed-off-by: Kuba Piecuch Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit ce0212d230bd6ad12db9b92f50e5cbf53349a150 Author: Yuho Choi Date: Sun May 24 23:38:46 2026 -0400 ARM: npcm: Fix OF node refcount leaks in SMP setup [ Upstream commit 8eb052f48331474c2789d07b7f11165c323bd2f9 ] npcm7xx_smp_boot_secondary() and npcm7xx_smp_prepare_cpus() look up the GCR and SCU nodes with of_find_compatible_node(). The returned nodes are used for of_iomap(), but the node references are never released. of_iomap() does not consume the device node reference, and iounmap() only releases the MMIO mapping. Drop each node reference after the corresponding mapping attempt. Fixes: 7bffa14c9aed ("arm: npcm: add basic support for Nuvoton BMCs") Signed-off-by: Yuho Choi Reviewed-by: Avi Fishman Signed-off-by: Andrew Jeffery Signed-off-by: Sasha Levin commit ccf6738adcafa5ddbddc4e71b45d8a51b86643c7 Author: Yun Zhou Date: Sun Jul 19 23:11:24 2026 +0800 xfs: handle NULL b_addr in xfs_buf_free [ Upstream commit d852729c5f4f830fbe7413df032e29459b3daf83 ] When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with bp->b_addr still NULL. The code falls through to the folio_put path which calls virt_to_folio(NULL), dereferencing an invalid address and causing a kernel crash. Call Trace: xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 Fix this by skipping folio_put() when bp->b_addr is NULL. Fixes: 5076a6040ca1 ("xfs: support in-memory buffer cache targets") Reported-by: syzbot+94c22d92f72f5a235b7d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=94c22d92f72f5a235b7d Signed-off-by: Yun Zhou Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit d90599a42f6c5e95ea70bfae3b9ae1b61e21230a Author: Daniel Drake Date: Thu Jul 16 21:45:27 2026 +0100 arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer [ Upstream commit 75952cfc7752c52a2b692b59d34ce160d3edabb2 ] Commit d87773de9efe1 ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE") causes boot to hang on Raspberry Pi 5. The newly-selected EL2 virtual timer does not generate any interrupts, even though the GIC_DIST_ENABLE_SET flag has been confirmed set via readback. It is highly unusual that this timer interrupt is non-operational because this is a standard GIC interrupt corresponding to a standard Cortex-A76 CPU timer. However, Broadcom have confirmed for this SoC: > the interrupt line was never connected in the first place as this was > not identified as being a requirement Remove the corresponding DeviceTree entry. Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/all/ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com/ Fixes: faa3381267d0 ("arm64: dts: broadcom: Add minimal support for Raspberry Pi 5") Signed-off-by: Daniel Drake Link: https://lore.kernel.org/r/20260716-bcm2712-el2-v2-1-e708f7fb42fa@reactivated.net Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit d71dfffa512e71b166a889484e4c3b148a9a3af2 Author: Anna Schumaker Date: Tue Jun 30 14:31:00 2026 -0400 NFS: Pin the 'struct nfs_server' during a FREE_STATEID call [ Upstream commit cf616096a0f3a2b60f7d68b6b39674a6867ded9c ] Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight. Reported-by: Dan Aloni Fixes: 7c1d5fae4a87 ("NFSv4: Convert nfs41_free_stateid to use an asynchronous RPC call") Tested-by: Dan Aloni Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit bd45b89d7346ff67b360e852cfbd10fafd1752f6 Author: Dmitry Baryshkov Date: Wed Apr 29 01:27:12 2026 +0300 arm64: dts: qcom: sdm850-lenovo-yoga-c630: lower PSCI cluster idle [ Upstream commit 07db10de262f4150e24fd631a7a6c428f7bf80c9 ] With the default PSCI suspend value for cluster idle state Lenovo Yoga C630 isn't stable enough. For example it might reset if display device isn't probed early enough. Drop the bit 0x4000 from the PSCI suspend value to make C630 work in stable way. The bit was found by expertimenting with the cluster idle PSCI value. Most likely it results in the less deep sleep and more energy beign spent in the suspend state, but it's better than the non-stable system behaviour. Fixes: a1ade6cac5a2 ("arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260429-c630-fix-idle-v2-1-ac867dad6f21@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit df9d22383d7c0186cabafd3ed09056cd22ad490f Author: Akhil P Oommen Date: Fri Apr 10 02:38:51 2026 +0530 arm64: dts: qcom: purwa: Fix GPU IOMMU property [ Upstream commit 4cd774c1feb3f720265c512174c5c3312eca1be2 ] Purwa's GPU does not support SID 1, which is typically used for LPAC-related traffic. Remove SID 1 from the GPU node's iommus property to accurately describe the hardware. This fixes the splat below, seen with some versions of Gunyah hypervisor: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 80 Comm: kworker/u33:2 Tainted: G M Tainted: [M]=MACHINE_CHECK Hardware name: Qualcomm Technologies, Inc. Purwa IoT EVK (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_write_s2cr+0x9c/0xbc lr : arm_smmu_master_install_s2crs+0x78/0xa4 sp : ffff80008039b570 x29: ffff80008039b570 x28: 0000000000000000 x27: ffffaddd62f1ab78 x26: ffff00080a4ff280 x25: 0000000000000018 x24: ffff00080b896480 x23: ffff00080ba9b7a0 x22: ffff00080bb05160 x21: 0000000000000000 x20: 0000000000000000 x19: 0000000000000001 x18: 00000000ffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008039b1d0 x14: ffff80010039b37d x13: 00746c7561662d74 x12: 0000000000000000 x11: ffff00080b7fbd98 x10: ffffffffffffffc0 x9 : ffffffffffffffff x8 : 0000000000000228 x7 : 0000000000000e87 x6 : 0000000000000000 x5 : 0000000000000000 x4 : ffff00080a4ff280 x3 : 0000000000000000 x2 : ffff800082a40c04 x1 : 0000000000000000 x0 : ffff800082a40000 Call trace: arm_smmu_write_s2cr+0x9c/0xbc (P) arm_smmu_master_install_s2crs+0x78/0xa4 arm_smmu_attach_dev+0xb0/0x1d8 __iommu_device_set_domain+0x84/0x11c __iommu_group_set_domain_internal+0x60/0x120 __iommu_attach_group+0x88/0x9c iommu_attach_device+0x6c/0xa0 msm_iommu_new.part.0+0x84/0xe4 [msm] msm_iommu_gpu_new+0x3c/0x104 [msm] adreno_iommu_create_vm+0x24/0xc8 [msm] a6xx_create_vm+0x48/0x78 [msm] msm_gpu_init+0x2d8/0x508 [msm] adreno_gpu_init+0x208/0x324 [msm] a6xx_gpu_init+0x604/0x8cc [msm] adreno_bind+0xb4/0x124 [msm] component_bind_all+0x114/0x23c msm_drm_init+0x1b0/0x1ec [msm] msm_drm_bind+0x30/0x3c [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x16c component_add+0x14/0x20 msm_dp_display_probe_tail+0x4c/0xac [msm] msm_dp_auxbus_done_probe+0x14/0x20 [msm] dp_aux_ep_probe+0x4c/0xf4 [drm_dp_aux_bus] really_probe+0xbc/0x29c __driver_probe_device+0x78/0x12c driver_probe_device+0x3c/0x15c __device_attach_driver+0xb8/0x134 bus_for_each_drv+0x88/0xe8 __device_attach+0xa0/0x190 device_initial_probe+0x50/0x54 bus_probe_device+0x38/0xa4 deferred_probe_work_func+0x88/0xc0 process_one_work+0x148/0x28c worker_thread+0x2cc/0x3d4 kthread+0x12c/0x204 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Fixes: 1aa0b4e36436 ("arm64: dts: qcom: x1p42100: Add GPU support") Signed-off-by: Akhil P Oommen Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260410-purwa-gpu-dt-fix-v1-1-4637892156cf@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7a6e90afb696ced494b1ef4c9306cc3b0307f914 Author: Dmitry Baryshkov Date: Thu Oct 30 20:20:15 2025 +0200 arm64: dts: qcom: rename x1p42100 to purwa [ Upstream commit ef659a5bd91bed7fae2c2a150f8ecca06599ac03 ] Follow the example of other platforms and rename X1P42100 to purwa.dtsi. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251030-rename-dts-2-v1-3-80c0b81c4d77@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 4cd774c1feb3 ("arm64: dts: qcom: purwa: Fix GPU IOMMU property") Signed-off-by: Sasha Levin commit 1e2b408c1a7695f4044f758a5f4dca76d5b3eb91 Author: Aleksandrs Vinarskis Date: Sat Sep 27 15:21:36 2025 +0200 arm64: dts: qcom: Rework X1-based Asus Zenbook A14's displays [ Upstream commit 462b39931cab3415ffc47863a58372399e600f4f ] The laptop comes in two variants: * UX3407RA, higher end, FHD+ OLED or WOXGA+ OLED panels * UX3407QA, lower end, FHD+ OLED or FHD+ LCD panels Even though all three panels work with "edp-panel", unfortunately the brightness adjustmenet of LCD panel is PWM based, requiring a dedicated device-tree. Convert "x1p42100-asus-zenbook-a14.dts" into ".dtsi" to allow for this split, introduce new LCD variant. Leave current variant without postfix and with the unchanged model name, as some distros (eg. Ubuntu) rely on this for automatic device-tree detection during kernel installation/upgrade. As dedicated device-tree is required, update compatibles of OLED variants to correct ones. Keep "edp-panel" as fallback, since it is enough to make the panels work. While at it moving .dts, .dtsi around, drop 'model' from the top level x1-asus-zenbook-a14.dtsi as well. Co-developed-by: Jens Glathe Signed-off-by: Jens Glathe Reviewed-by: Konrad Dybcio Signed-off-by: Aleksandrs Vinarskis Link: https://lore.kernel.org/r/20250927-zenbook-improvements-v3-2-d46c7368dc70@vinarskis.com Signed-off-by: Bjorn Andersson Stable-dep-of: 4cd774c1feb3 ("arm64: dts: qcom: purwa: Fix GPU IOMMU property") Signed-off-by: Sasha Levin commit 387edbe4706b67afd3ba74fcff26eab093671399 Author: Dmitry Baryshkov Date: Tue Sep 23 14:01:55 2025 +0300 arm64: dts: qcom: rename x1e80100 to hamoa [ Upstream commit 8c0b058ab5983a4be6690a76be9b0294853e8e55 ] The X1E80100 and several other similar names (X1E78100, X1E001DE) all belong to the platform now known as 'hamoa'. Follow the example of 'lemans' and rename the x1e80100.dtsi to hamoa.dtsi and x1e80100-pmics.dtsi to hamoa-pmics.dtsi. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250923-rename-dts-v1-2-21888b68c781@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 4cd774c1feb3 ("arm64: dts: qcom: purwa: Fix GPU IOMMU property") Signed-off-by: Sasha Levin commit d089f32d34f821c8f0ef23d5fcd77bd43c1b3b92 Author: Ray Wu Date: Wed Aug 5 09:47:17 2026 +0800 drm/amd/display: Check for tg ops in dce110_set_avmute [ Upstream commit 3141e3d61469bba2624a91c5e2407f110b33b29e ] Some older DCE timing generators do not implement is_tg_enabled in their ops table. Calling it unconditionally when waiting for AV mute frames causes a NULL pointer dereference on Southern Islands dGPUs when turning the display off over HDMI. Check that tg and the required ops exist before waiting for frames. Fixes: 414da24137ac ("drm/amd/display: Add AV mute wait frames to dce110_set_avmute") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5557 Tested-by: Viktor Jägersküpper Signed-off-by: Ray Wu Signed-off-by: Alex Deucher (cherry picked from commit 2686a0c0aaa07bec2e24131835cf27b5fd4935a5) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8aba384bfc8aac800335f0f458c4e77fc7223e48 Author: Ray Wu Date: Mon Jul 13 22:23:34 2026 +0800 drm/amd/display: Add AV mute wait frames to dce110_set_avmute [ Upstream commit 443290d70b01e9c35830c300e3247c06581b594c ] Port the three-frame wait logic from dcn30_set_avmute to dce110_set_avmute so that older DCN versions (1.0, 2.0) also wait for GCP packets to be sent out before proceeding. This ensures HDMI sinks properly process the mute state, preventing garbled display after link re-establishment. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5167 Reviewed-by: Wayne Lin Signed-off-by: Ray Wu Signed-off-by: Fangzhi Zuo Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 414da24137ace80d8c59fefd43ba3ec9f5f854ba) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 50359c42e0ebad6daafbf7a5e016d03e3cd7b3ba Author: Michal Luczaj Date: Sat Aug 8 09:41:11 2026 -0300 selftests/bpf: Fail unbound UDP on sockmap update [ Upstream commit 203b06932777b9ad5085319389dea566f5c2ca63 ] sockmap now rejects unbound UDP sockets. Adjust test_maps. While at it, check socket()'s return value. This effectively reverts commit c39aa2159974 ("bpf, selftests: Fix test_maps now that sockmap supports UDP"). Signed-off-by: Michal Luczaj Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20260707-sockmap-lookup-udp-leak-v4-4-f878346f27ab@rbox.co Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Ricardo B. Marlière (SUSE) Signed-off-by: Sasha Levin commit 62fefb817bb3b6cd839a27c77b2fb81229dc72cc Author: Peter Zijlstra Date: Wed Apr 15 21:10:53 2026 +0000 sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") [ Upstream commit 101f3498b4bdfef97152a444847948de1543f692 ] Zicheng Qu reported that, because avg_vruntime() always includes cfs_rq->curr, when ->on_rq, place_entity() doesn't work right. Specifically, the lag scaling in place_entity() relies on avg_vruntime() being the state *before* placement of the new entity. However in this case avg_vruntime() will actually already include the entity, which breaks things. Also, Zicheng Qu argues that avg_vruntime should be invariant under reweight. IOW commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") was wrong! The issue reported in 6d71a9c61604 could possibly be explained by rounding artifacts -- notably the extreme weight '2' is outside of the range of avg_vruntime/sum_w_vruntime, since that uses scale_load_down(). By scaling vruntime by the real weight, but accounting it in vruntime with a factor 1024 more, the average moves significantly. However, that is now cured. Tested by reverting 66951e4860d3 ("sched/fair: Fix update_cfs_group() vs DELAY_DEQUEUE") and tracing vruntime and vlag figures again. Reported-by: Zicheng Qu Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: Shubhang Kaushik Link: https://patch.msgid.link/20260219080625.066102672%40infradead.org (cherry picked from commit 101f3498b4bdfef97152a444847948de1543f692) [jstultz: Resolved minor collision in the revert against 6.18-stable] Signed-off-by: John Stultz Signed-off-by: Sasha Levin commit 4043e196dc88223802e78065b4b52cbd949eba55 Author: Ingo Molnar Date: Wed Nov 26 05:31:28 2025 +0100 sched/fair: Separate se->vlag from se->vprot [ Upstream commit 80390ead2080071cbd6f427ff8deb94d10a4a50f ] There's no real space concerns here and keeping these fields in a union makes reading (and tracing) the scheduler code harder. Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20251201064647.1851919-4-mingo@kernel.org Signed-off-by: Sasha Levin commit 9a3eef676cd8b5d823cef123347d0900d88df32b Author: Al Viro Date: Fri Aug 7 13:38:27 2026 +0300 mount: honour SB_NOUSER in the new mount API [ Upstream commit 6dd3c6884cd9defb511284b566cef5ac8f657dbf ] One should *not* be allowed to mount one of those, new API or not. Reported-by: Denis Arefev Signed-off-by: Al Viro Link: https://patch.msgid.link/20260602020444.GP2636677@ZenIV Signed-off-by: Christian Brauner (Amutable) [Denis: rename new_mnt -> newmount.mnt] [Denis: use goto err_unlock instead of direct return] Signed-off-by: Denis Arefev Signed-off-by: Sasha Levin commit 79a45d44323b3d2429ad9d8f3f01747bde08d49e Author: Farhan Ali Date: Fri Aug 7 12:22:18 2026 -0700 KVM: s390: pci: Fix resource leak on IRQ registration failure [ Upstream commit 5580c9858f1e00f60191eb09c3add359836d60b6 ] Currently if kvm_zpci_set_airq() fails, kvm_s390_pci_aif_enable() returns the error code but doesn't do any resource cleanup thus leaking resources. Fix this by cleaning up all the resources such as the GAITE, AIBV, AISB and unpinning any pinned pages. While at it, remove dead code that stored FIB values that were never referenced. As part of the cleanup, we are also holding the aift_lock a bit longer, as we hold the lock while executing the MPCIFC instruction. Though this is not strictly necessary, it means we don't have to drop and re-acquire in the error case. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Reviewed-by: Christian Borntraeger Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin