commit 79a9660d699e69fa523d2c3d1d8af95d6b857c93 Author: Greg Kroah-Hartman Date: Thu Aug 27 14:29:06 2026 +0200 Linux 6.1.185 Link: https://lore.kernel.org/r/20260825132541.677185791@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Salvatore Bonaccorso Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 37a5dcd6837fc2afc44a7bc3ed8af4e983783d46 Author: Eric Dumazet Date: Thu Aug 27 06:40:25 2026 +0000 net: gro: properly validate BIG TCP aggregation criteria When GRO attempts to aggregate IPv6 packets beyond GRO_LEGACY_MAX_SIZE (64KB), the aggregate should only be permitted for plain IPv6 TCP flows that have sufficient MAC header room to insert the temporary HBH jumbo header. In 6.1.y, skb_gro_receive() had two issues with this check: 1. It checked skb_headroom(p) instead of the actual space before the MAC header (p->mac_header). Because skb_headroom(p) measures (data - head), it 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 checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark, which is 0 during receive, failing to reject encapsulated IPv6 flows (such as IP6IP6). Fix skb_gro_receive() to strictly check: - p->protocol == htons(ETH_P_IPV6) - p->mac_header >= sizeof(struct hop_jumbo_hdr) - ipv6_hdr(p)->nexthdr == IPPROTO_TCP - Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation) 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") Reported-by: Sam Dlinn Signed-off-by: Eric Dumazet Signed-off-by: Greg Kroah-Hartman commit 8e68c380290b1dd64a0a512ce66d0264130c46ed 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 8614c043b11cc35ffebd35542ab4da275f8f923d 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 d37ff4e3635c18af907f25712596f8ccec323751 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 634f498ea5d5e8e01f8d9414d4f45eeaf9ee1996 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 33ea29f8b6141f2d265de807e110a6435b355cb0 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 4753cc37b6606ef9a7ec22861d380d45e2707f9a Author: Sukrut Bellary Date: Mon Sep 2 15:14:09 2024 +0100 misc: fastrpc: Fix double free of 'buf' in error path commit e8c276d4dc0e19ee48385f74426aebc855b49aaf upstream. smatch warning: drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf' In fastrpc_req_mmap() error path, the fastrpc buffer is freed in fastrpc_req_munmap_impl() if unmap is successful. But in the end, there is an unconditional call to fastrpc_buf_free(). So the above case triggers the double free of fastrpc buf. Fixes: 72fa6f7820c4 ("misc: fastrpc: Rework fastrpc_req_munmap") Reviewed-by: Shuah Khan Reviewed-by: Dan Carpenter Reviewed-by: Srinivas Kandagatla Signed-off-by: Sukrut Bellary Signed-off-by: Srinivas Kandagatla Cc: stable Link: https://lore.kernel.org/r/20240902141409.70371-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2753722612d8824d3910096f93059f669009b0f0 Author: Oliver Hartkopp Date: Tue Aug 25 14:27:15 2026 +0200 can: isotp: fix timer drain order, wakeup handling and tx_gen ordering commit 050f010f920da17c1044a4f174766ad553e770b6 upstream. This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator. Fixes: cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260724181525.43556-1-socketcan@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman commit cadee54a8691e40bf04f2ac4a108b413b8c88ef8 Author: Oliver Hartkopp Date: Tue Aug 25 14:27:14 2026 +0200 can: use skb hash instead of private variable in headroom commit d4fb6514ff8ed6912a71294e6b66a5d59ee88007 upstream. The can_skb_priv::skbcnt variable is used to identify CAN skbs in the RX path analogue to the skb->hash. As the skb hash is not filled in CAN skbs move the private skbcnt value to skb->hash and set skb->sw_hash accordingly. The skb->hash is a value used for RPS to identify skbs. Use it as intended. Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260201-can_skb_ext-v8-1-3635d790fe8b@hartkopp.net Signed-off-by: Paolo Abeni Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman commit eb6b7753e8f75ffe14602ee2afd45ad6363abf57 Author: Donglin Lyu Date: Mon Aug 24 11:34: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 d7d4a8a75cd3f160c089e808433241c3c5bf75b9 Author: Cryolitia PukNgae Date: Mon Aug 24 11:34: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 17e01e342af74de12899c206dcc9ec90684703aa Author: Eric Farman Date: Tue Jul 28 05:30:13 2026 +0200 s390/vfio_ccw: Free all memory if cp_init() fails [ Upstream commit 74186c2968f8f756ac3226b545b598457c910c75 ] 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: Sasha Levin commit f833821e4b52ab6335d443ede5fb79c38e61d19a 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 313ead1abed945544703b100a12c5a10fdf78409 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 da86a2bf716ff2bb1bced0a1bebd48d0765ff355 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 403cc9bd6ccb9fbe68d501c3236e5a6dd5504e14 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 e19f1e37f93d78d8a18c24e82b1eb4b1752d807f Author: Qing Luo Date: Mon Aug 24 19:50:40 2026 -0400 mptcp: pm: fix data race in add_addr timer callback [ Upstream commit a7aad5b69d3bdaec20a3ed9284e184502450c0cd ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5da972efed3dc7599da6e2b5e8d906d1b7b1a728 Author: Matthieu Baerts (NGI0) Date: Mon Aug 24 19:50:39 2026 -0400 mptcp: pm: ADD_ADDR rtx: free sk if last [ Upstream commit b7b9a461569734d33d3259d58d2507adfac107ed ] When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-5-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: a7aad5b69d3b ("mptcp: pm: fix data race in add_addr timer callback") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81d8142148164176385c279c7c1e1d581867423d Author: Matthieu Baerts (NGI0) Date: Mon Aug 24 19:50:38 2026 -0400 mptcp: pm: ADD_ADDR rtx: always decrease sk refcount [ Upstream commit 9634cb35af17019baec21ca648516ce376fa10e6 ] When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-4-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: a7aad5b69d3b ("mptcp: pm: fix data race in add_addr timer callback") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f84f2c81d792cf1e65571108a3bdd2c29e09e995 Author: Dawid Wróbel Date: Mon Aug 24 18:06:51 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 84b205297fa15f97510342221d8c9a0119711478 Author: Linmao Li Date: Mon Aug 24 11:01:07 2026 -0400 Input: byd - synchronize timer deletion before freeing private data [ Upstream commit c83e79c0842ed29860648bcce5022ef0ba5001c6 ] 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 [ changed `del_timer()` to `timer_shutdown_sync()` since 6.12 predates the `del_timer()` → `timer_delete()` rename ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7077e6c45423dd2bb7de7b5fc4b018a8e6c4741 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 1a8f007faefe8c226ec65896589f8d59b0a8d5a5 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 447b668faa14710f611e714031e3739ac3ec3a4f 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 d960881b9312e781a3429aabceb223ce6b7c882f 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 74ce7389f8f562d39015f59a00ef7ad6acd37803 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 f161be39201eb5f9b1f58fb8f90b8a9cd3931eb6 Author: Pavitra Jha Date: Wed Jul 8 01:39:41 2026 -0400 libceph: fix OOB read in decode_watchers() via missing bounds check commit 00ead17c7de137a692edee59f2772e6af687e8eb upstream. 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 2ff70a8edba13dc402d1b9173120dabdb7dff5a6 Author: Eric Dumazet Date: Fri Feb 14 14:07:05 2025 +0000 ndisc: ndisc_send_redirect() cleanup commit 0784d83df3bfc977c13252a0599be924f0afa68d upstream. ndisc_send_redirect() is always called under rcu_read_lock(). It can use dev_net_rcu() and avoid one redundant rcu_read_lock()/rcu_read_unlock() pair. Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250214140705.2105890-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Li Xiasong Signed-off-by: Greg Kroah-Hartman commit be678c7a41eb3239f9dccc1dce406844fc8d6776 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 fe69fed3495f676578d49414a069ad7d8468e2ce 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 afd8605fb43becb892311102844955c3b127fc7e 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 dd26d30f40c43ad9cfe2f25c6ea0ead1dd51d5aa 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 d63e85c5d5555fe6aa65155d3a09452597e163c3 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 a7b9b449f5a5132221fff6adc11a9431ab8cd914 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 9c47d667963542c3cf8e3007b7f10c0904d08238 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 65a0ec7783b06068dda6745dd689bf4a91ee64aa 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 cb298672282421159e53ab311fe49d204c8a52da 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 8d2c243b79854628ff076c38748c020042f02f57 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 4e942da2869bcd646353eef706b7dd82efeb9db5 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 b8c9f25fd84328c5fcc4f70c6d1e8f1d4787eaac Author: Joanne Koong Date: Mon Sep 22 11:00:42 2025 -0700 iomap: adjust read range correctly for non-block-aligned positions commit 7aa6bc3e8766990824f66ca76c19596ce10daf3e upstream. iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks. Signed-off-by: Joanne Koong Tested-by: syzbot@syzkaller.appspotmail.com Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Greg Kroah-Hartman commit ef50eaab631f9bf519ddbdfa42ccb0528adc1fc8 Author: Jakub Kicinski Date: Thu Aug 7 16:29:06 2025 -0700 tls: handle data disappearing from under the TLS ULP commit 6db015fc4b5d5f63a64a193f65d98da3a7fc811d upstream. TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARN_ON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry. We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len). If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place. Reported-by: William Liu Reported-by: Savino Dicanosa Link: https://lore.kernel.org/tFjq_kf7sWIG3A7CrCg_egb8CVsT_gsmHAK0_wxDPJXfIzxFAMxqmLwp3MlU5EHiet0AwwJldaaFdgyHpeIUCS-3m3llsmRzp9xIOBR4lAI=@syst3mfailure.io Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250807232907.600366-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Assisted-by: Codex:GPT-5 Signed-off-by: Artem Dinaburg Signed-off-by: Greg Kroah-Hartman commit 6509e270ae1b4366a95f8d75b0dafec7b6f9e7a8 Author: Sabrina Dubroca Date: Wed Apr 24 12:25:47 2024 +0200 tls: fix lockless read of strp->msg_ready in ->poll commit 0844370f8945086eb9335739d10205dcea8d707b upstream. tls_sk_poll is called without locking the socket, and needs to read strp->msg_ready (via tls_strp_msg_ready). Convert msg_ready to a bool and use READ_ONCE/WRITE_ONCE where needed. The remaining reads are only performed when the socket is locked. Fixes: 121dca784fc0 ("tls: suppress wakeups unless we have a full record") Signed-off-by: Sabrina Dubroca Link: https://lore.kernel.org/r/0b7ee062319037cf86af6b317b3d72f7bfcd2e97.1713797701.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Stable-dep-of: 0844370f8945 ("tls: fix lockless read of strp->msg_ready in ->poll") Assisted-by: Codex:GPT-5 Signed-off-by: Artem Dinaburg Signed-off-by: Greg Kroah-Hartman commit 63d2230e5076c12f93d2a1d1bff2fbbf6cf32f3c 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 0514f3054738de60da8544586de27628ffcdcd3d Author: Yang Wang Date: Mon Aug 24 07:21:59 2026 -0400 drm/amdgpu: check ASPM on the dGPU host link [ Upstream commit 2a9c5154a5650c09ad44ff5e1dff74754e15a3c6 ] 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 [ Dropped the upstream APU and `amdgpu_device_aspm_support_quirk(adev)` context lines, keeping 6.1's old-signature quirk helper untouched. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7b5fa83e2c192be922121b764415fa8c7549ea1 Author: Ibrahim Hashimov Date: Mon Aug 24 05:56:50 2026 -0400 xfs: bounds-check buffer log item's dirty bitmap [ Upstream commit 813f8136a2ce1fee266d02a7df73db6e8a541604 ] 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 [ dropped the `xlog_recover_do_primary_sb_buffer()` error-propagation hunk and its primary-SB/rtsb arm since that helper doesn't exist, keeping only the `error = 0;` reset ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cacb1245edf4b0b2d30e3319ba545d7ec5631a1d Author: Christoph Hellwig Date: Mon Aug 24 05:56:49 2026 -0400 xfs: don't use a xfs_log_iovec for ri_buf in log recovery [ Upstream commit ded74fddcaf685a9440c5612f7831d0c4c1473ca ] ri_buf just holds a pointer/len pair and is not a log iovec used for writing to the log. Switch to use a kvec instead. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Stable-dep-of: 813f8136a2ce ("xfs: bounds-check buffer log item's dirty bitmap") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0edd222730a9d7ec98368aaf1d40ee2d8d862e61 Author: Eric Farman Date: Mon Aug 24 05:56:30 2026 -0400 s390/vfio_ccw: Implement a crw lock [ Upstream commit 16b0798024c0e9117e395829ddbbe70981c79d9c ] 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 [ Relocated the `spin_lock_init()` and CRW drain loop from `vfio_ccw_mdev_init_dev()`/`release_dev()` in ops.c to `vfio_ccw_alloc_private()`/`vfio_ccw_free_private()` in drv.c, and kept the 2-argument `eventfd_signal()` form. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56d7488533ceac4e986e96e15c9e487a2245bc01 Author: Eric Farman Date: Mon Aug 24 05:56:29 2026 -0400 s390/vfio_ccw: Selectively expand io_mutex [ Upstream commit 34f4feff3e90bd09308fad0974e97113b23b812a ] 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 Stable-dep-of: 16b0798024c0 ("s390/vfio_ccw: Implement a crw lock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c9b85aa2cf73ea645e55e2c2670e0ddebfe1589b Author: Eric Farman Date: Mon Aug 24 05:56:28 2026 -0400 s390/vfio_ccw: Move cp cleanup out of not operational [ Upstream commit 0c11f61a876ed6fcca53d442ed3f33ea8362a0f9 ] 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 Stable-dep-of: 16b0798024c0 ("s390/vfio_ccw: Implement a crw lock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7e9954e7212042ec808b06181b365b14f00c6f0a Author: Junrui Luo Date: Sun Aug 23 20:12:07 2026 -0400 drm/amdgpu: disallow multiple FENCE chunks in one submit [ Upstream commit 931cd1d1baeae68e8eb2c23bc1f3d8934dca6241 ] 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) [ adapted `p->uf_bo` to the pre-drm_exec field spelling `p->uf_entry.tv.bo` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b94b28c1f0fae53b2f2d6180ae6442c9a1558f67 Author: Eric Farman Date: Sun Aug 23 14:04:18 2026 -0400 s390/vfio_ccw: Cancel existing workqueues [ Upstream commit 79c60b2c61105368dcc8444eb45847e21734f7c4 ] 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 [ Inserted the two cancel_work_sync() calls before the memset/complete pair in 6.1's release_dev instead of upstream's destructor body, which doesn't exist here. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08a04d7bfb9c103432561aff8a62b6872e694a6a Author: Zhiling Zou Date: Fri Aug 21 19:11:14 2026 -0400 inet: frags: publish queues before arming timer [ Upstream commit 653d7ddf6cba867777a3d14c4f83ace008c5ad13 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f015c9de92b731814059a343b765c60c0196225c Author: Zihan Xi Date: Fri Aug 21 10:49:40 2026 -0400 packet: synchronize pressure clearing with ring reconfiguration [ Upstream commit 1a35da325cac4d5bcad76a2aa943408a6f1d9000 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 88ecc4e120bcef398434d1e50c88ebcc4dd989cf Author: Eric Dumazet Date: Fri Aug 21 10:49:39 2026 -0400 net/packet: convert po->pressure to an atomic flag [ Upstream commit 791a3e9f1a86fe8eb09173c9788493b8b5c957f4 ] Not only this removes some READ_ONCE()/WRITE_ONCE(), this also removes one integer. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: 1a35da325cac ("packet: synchronize pressure clearing with ring reconfiguration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d40a28ab302e115d6ea1c64b081917e8c76d18af Author: Luca Fresi Date: Fri Aug 21 10:49:34 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 b0c3604f816cf344751436f7a2b5a294cf386f1e Author: Hugo Villeneuve Date: Fri Aug 21 10:49:33 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 d11f15dbbf83a387e5b1c5e3ea5491e01226e2e6 Author: Hugo Villeneuve Date: Fri Aug 21 10:49:32 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 739499f1da1a4ee2caba849d0288fa900e1b276b Author: Lech Perczak Date: Fri Aug 21 10:49:31 2026 -0400 serial: sc16is7xx: convert bitmask definitions to use BIT() macro [ Upstream commit d2e8590fd1048c5c0dba160edc6a48ee8305a1f0 ] Now that bit definition comments were cleaned up, convert bitmask definitions to use BIT() macro for clarity. Convert SC16IS7XX_IIR_ID_MASK to use GENMASK() macro - - while at that, realign comments. Compose SC16IS7XX_LSR_BRK_ERROR_MASK using aforementioned constants, instead of open-coding it, and remove now unneeded comments. Signed-off-by: Lech Perczak Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/8b45a01e-7cc5-4d53-b467-c6680bc51ef4@camlingroup.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 7a11226e02f56083c10de7d7fa6ba13c9b79ff30 Author: Lech Perczak Date: Fri Aug 21 10:49:30 2026 -0400 serial: sc16is7xx: fix copy-paste errors in EFR_SWFLOWx_BIT constants [ Upstream commit eccdb0fd1c340155666533f5c60c5229d370baab ] Comments attached to bits 0 and 1 incorrectly referenced bits 2 and 3, which don't match the datasheet - fix them. At the same time remove comments for individual constants, as they add nothing to the definitions themselves. Signed-off-by: Lech Perczak Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/2986a485-935d-4ab2-9a16-4a85288aa15a@camlingroup.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 e79f59a8527a49078cfaf8fe8fb5fcefc20c76d2 Author: Qihang Tang Date: Fri Aug 21 07:00:17 2026 -0400 packet: use consistent hard_header_len in TX_RING send path [ Upstream commit 21b5953e7494c16a42e6cd8cf110e18d13ae4a6b ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 142e287b3a25cfe909215177c23243e7fc5ae2b1 Author: Qihang Tang Date: Fri Aug 21 07:00:16 2026 -0400 packet: use consistent hard_header_len in non-ring send paths [ Upstream commit 03390aa32e669cc4ecd7d34108e2e1afc13d689d ] 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 Stable-dep-of: 21b5953e7494 ("packet: use consistent hard_header_len in TX_RING send path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f8a07021679aadfb6d63b209207ccc41f26982d1 Author: Aditya Chillara Date: Thu Aug 20 23:59:40 2026 -0400 perf/core: Fix group leader use-after-free after sibling detach [ Upstream commit 42c5ca1f0a288a52878bd72a5595b08261057438 ] 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 [ adjusted `event_sched_out()` calls to the older three-argument form taking `cpuctx` and kept the existing `event->pending_disable = 1;` in the DETACH_DEAD path ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b1e5c44653fdbd26da9366193adc935245f2755 Author: Yeoreum Yun Date: Thu Aug 20 23:59:39 2026 -0400 perf: Fix dangling cgroup pointer in cpuctx [ Upstream commit 3b7a34aebbdf2a4b7295205bf0c654294283ec82 ] Commit a3c3c6667("perf/core: Fix child_total_time_enabled accounting bug at task exit") moves the event->state update to before list_del_event(). This makes the event->state test in list_del_event() always false; never calling perf_cgroup_event_disable(). As a result, cpuctx->cgrp won't be cleared properly; causing havoc. Fixes: a3c3c6667("perf/core: Fix child_total_time_enabled accounting bug at task exit") Signed-off-by: Yeoreum Yun Signed-off-by: Peter Zijlstra (Intel) Tested-by: David Wang <00107082@163.com> Link: https://lore.kernel.org/all/aD2TspKH%2F7yvfYoO@e129823.arm.com/ Stable-dep-of: 42c5ca1f0a28 ("perf/core: Fix group leader use-after-free after sibling detach") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6449c4223b53495bfb2ddde72a519734033a18e6 Author: Peter Zijlstra Date: Thu Aug 20 23:59:38 2026 -0400 perf: Fix cgroup state vs ERROR [ Upstream commit 61988e36dc5457cdff7ae7927e8d9ad1419ee998 ] While chasing down a missing perf_cgroup_event_disable() elsewhere, Leo Yan found that both perf_put_aux_event() and perf_remove_sibling_event() were also missing one. Specifically, the rule is that events that switch to OFF,ERROR need to call perf_cgroup_event_disable(). Unify the disable paths to ensure this. Fixes: ab43762ef010 ("perf: Allow normal events to output AUX data") Fixes: 9f0c4fa111dc ("perf/core: Add a new PERF_EV_CAP_SIBLING event capability") Reported-by: Leo Yan Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250605123343.GD35970@noisy.programming.kicks-ass.net Stable-dep-of: 42c5ca1f0a28 ("perf/core: Fix group leader use-after-free after sibling detach") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fe9b3b9e4b84a8cbec69949baf812e30feb3941 Author: Yeoreum Yun Date: Thu Aug 20 23:59:37 2026 -0400 perf/core: Fix child_total_time_enabled accounting bug at task exit [ Upstream commit a3c3c66670cee11eb13aa43905904bf29cb92d32 ] The perf events code fails to account for total_time_enabled of inactive events. Here is a failure case for accounting total_time_enabled for CPU PMU events: sudo ./perf stat -vvv -e armv8_pmuv3_0/event=0x08/ -e armv8_pmuv3_1/event=0x08/ -- stress-ng --pthread=2 -t 2s ... armv8_pmuv3_0/event=0x08/: 1138698008 2289429840 2174835740 armv8_pmuv3_1/event=0x08/: 1826791390 1950025700 847648440 ` ` ` ` ` > total_time_running with child ` > total_time_enabled with child > count with child Performance counter stats for 'stress-ng --pthread=2 -t 2s': 1,138,698,008 armv8_pmuv3_0/event=0x08/ (94.99%) 1,826,791,390 armv8_pmuv3_1/event=0x08/ (43.47%) The two events above are opened on two different CPU PMUs, for example, each event is opened for a cluster in an Arm big.LITTLE system, they will never run on the same CPU. In theory, the total enabled time should be same for both events, as two events are opened and closed together. As the result show, the two events' total enabled time including child event is different (2289429840 vs 1950025700). This is because child events are not accounted properly if a event is INACTIVE state when the task exits: perf_event_exit_event() `> perf_remove_from_context() `> __perf_remove_from_context() `> perf_child_detach() -> Accumulate child_total_time_enabled `> list_del_event() -> Update child event's time The problem is the time accumulation happens prior to child event's time updating. Thus, it misses to account the last period's time when the event exits. The perf core layer follows the rule that timekeeping is tied to state change. To address the issue, make __perf_remove_from_context() handle the task exit case by passing 'DETACH_EXIT' to it and invoke perf_event_state() for state alongside with accounting the time. Then, perf_child_detach() populates the time into the parent's time metrics. After this patch, the bug is fixed: sudo ./perf stat -vvv -e armv8_pmuv3_0/event=0x08/ -e armv8_pmuv3_1/event=0x08/ -- stress-ng --pthread=2 -t 10s ... armv8_pmuv3_0/event=0x08/: 15396770398 32157963940 21898169000 armv8_pmuv3_1/event=0x08/: 22428964974 32157963940 10259794940 Performance counter stats for 'stress-ng --pthread=2 -t 10s': 15,396,770,398 armv8_pmuv3_0/event=0x08/ (68.10%) 22,428,964,974 armv8_pmuv3_1/event=0x08/ (31.90%) [ mingo: Clarified the changelog. ] Fixes: ef54c1a476aef ("perf: Rework perf_event_exit_event()") Suggested-by: Peter Zijlstra Signed-off-by: Yeoreum Yun Signed-off-by: Ingo Molnar Tested-by: Leo Yan Link: https://lore.kernel.org/r/20250326082003.1630986-1-yeoreum.yun@arm.com Stable-dep-of: 42c5ca1f0a28 ("perf/core: Fix group leader use-after-free after sibling detach") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f70c9d4fba46463a5b1c7b3ee9ee3b40c90dac03 Author: Fan Wu Date: Thu Aug 20 23:59:30 2026 -0400 serial: amba-pl011: synchronize DMA teardown [ Upstream commit 440915499231e9db1c361aa45bb702e8fd3b4a32 ] 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 [ changed upstream's `timer_delete_sync()` deletion to match this tree's `del_timer_sync()` spelling at the old call site ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 272df0fbe6f3e04e22bc67fbdd9ac24586b942f4 Author: Koichiro Den Date: Thu Aug 20 23:59:23 2026 -0400 NTB: ntb_netdev: Preserve RX queue depth on allocation failure [ Upstream commit d2121faf133ac3bf9531b53a7e21273649a08517 ] 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 [ kept HEAD's `struct net_device *ndev = qp_data;` declaration instead of the per-queue context variables, adding only `new_skb` to the existing `skb` declaration ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 99f8de36c84cb9b872157aa6c3578c2480cee4b8 Author: Ekansh Gupta Date: Thu Aug 20 10:55:01 2026 -0400 misc: fastrpc: Remove buffer from list prior to unmap operation [ Upstream commit 6102ceb4eab845743ee57acd3863fbd06e93c927 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13327ed95222e70fa98805382b65636b872d87cb Author: Abel Vesa Date: Thu Aug 20 10:55:00 2026 -0400 misc: fastrpc: Rework fastrpc_req_munmap [ Upstream commit 72fa6f7820c4cf96c5f7aabc4e54bdf52d1e2ac2 ] Move the lookup of the munmap request to the fastrpc_req_munmap and pass on only the buf to the lower level fastrpc_req_munmap_impl. That way we can use the lower level fastrpc_req_munmap_impl on error path in fastrpc_req_mmap to free the buf without searching for the munmap request it belongs to. Co-developed-by: Srinivas Kandagatla Signed-off-by: Abel Vesa Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20221125071405.148786-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 6102ceb4eab8 ("misc: fastrpc: Remove buffer from list prior to unmap operation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03a12253dd2a036545bdb0110a4e0b8dc70f8e7c 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 d1efdcb372879d986b08071f89a135ee8b7da97f 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 8865cd664484517703df5c18a965dc3227572b87 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 5dc59fc959b2b5742985d7ef24bccd1868217dc2 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 41dd31117565b4654e206341bdbe1e3e206bbd5b 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 b4663405ae29d36011cd712d243456f3f9ab700d 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 4d0892a90b57f0e89b274c3f3c51c2fa17937c88 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 f8e6fde5db87f855e99b200e392467274f0eb9d7 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 56f0aa75c7640e46397ef73bea251fcbef9150c0 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 baf9b0383ff770fdff123d3a832f3a99641d96dd 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