commit 7fdb7c1824a1f9979d648d7ae28ac446bcee9c6e Author: Greg Kroah-Hartman Date: Thu Oct 15 11:56:43 2026 +0200 Linux 6.12.113 Link: https://lore.kernel.org/r/20261013112907.864180619@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: SJ Park Tested-by: Miguel Ojeda Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Dominique Martinet Tested-by: Brett A C Sheffield Link: https://lore.kernel.org/r/20261014123803.944920639@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: SJ Park Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 6bce4b221dc0e144180c333123dbb82d1dc3a500 Author: Vicki Pfau Date: Tue Oct 13 09:11:43 2026 +0000 HID: steam: Clean up locking [ Upstream commit de1d341b9b3ec9655f31fb8b44f784cca5e670ad ] This cleans up several issues with locking behavior, including RCU accesses not being guarded behind a lock. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina [Lee: Drop report_mutex from steam_get_serial() instead of steam_exchange_report_id() and omit sensor open/close, coalesce_rumble_work and Ibex changes as a0fbd9437d7d, 1d4549fd1115, fcfa7db89f7a and 0a80b4e8ec6a are not present] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2b15e10aff95c78dbacc4fa32fa90c9098213e03 Author: Vicki Pfau Date: Tue Oct 13 09:11:42 2026 +0000 HID: steam: Refactor registration [ Upstream commit 6f9b740c31ba7e061b2ebb330d9a3d63f1358f29 ] This refactors and simplifies the registration/unregistration flow. Since we now only perform registration when the client isn't opened anymore, the logic for handling that can be removed, and the rest of the function streamlined. We also remove the previous assumption that we have a serial number to show we're registered, replacing it with a single purpose boolean. In a previous refactor the code for unregistering a battery if later registration steps failed was accidentally left out. As a result, a lingering power_supply object could get left over after the steam object was torn down. This is also fixed here. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina [Lee: Omit steam_get_attributes() and coalesce_rumble_work cancellation as a0fbd9437d7d and 1d4549fd1115 are not present] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 81a8209c09f9be7eef860ca6cc154749a6b4d243 Author: Vicki Pfau Date: Tue Oct 13 09:11:41 2026 +0000 HID: steam: Rearrange teardown sequence [ Upstream commit ddce9641ce924ed91ec8304577e463823a29ffaf ] This fixes a narrow window during the teardown sequence where callbacks could still be scheduled during cleanup that would then have a dangling pointer to the now-freed steam struct. This also puts work canceling for rumble and mode switch in steam_unregister, as that shouldn't persist while the client hdev is open. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina [Lee: Omit coalesce_rumble_work cancellation as 1d4549fd1115 ("HID: steam: Coalesce rumble packets") is not present] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 295e46fcd16ad5b78bf32bcfa99d7f3a4f2ac3b8 Author: Vicki Pfau Date: Tue Oct 13 09:11:40 2026 +0000 HID: steam: Fully unregister controller when hidraw is opened [ Upstream commit cd33a91d37eb4d7c6ce56aa7f4688066309808eb ] To avoid conflicts between anything touching the hidraw and the driver we had previously detached the evdev nodes when the hidraw is opened. However, this isn't sufficient to avoid FEATURE reports from conflicting, so we change to fully unregistering the controller internally, leaving only the hidraw active until it's closed. This also unifies the unregister and connect callbacks, as now the logic between these two callbacks is identical. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina [Lee: Omit coalesce_rumble_work cancellation as 1d4549fd1115 ("HID: steam: Coalesce rumble packets") is not present] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ffe63be29f0db085bf2d3c0d5fe3d17b80778d4b Author: Kuba Piecuch Date: Tue Oct 13 09:02:25 2026 +0000 sched_ext: Generate qseq from a per-task counter commit e6ac89b8b1c12e9104df45a14a26e2dfa96ded06 upstream. finish_dispatch() uses the qseq embedded in p->scx.ops_state to tell whether the QUEUED instance of a task it's about to claim is the one scx_bpf_dsq_insert() saw. qseq is generated from rq->scx.ops_qseq, but the counters of different rqs are independent, so if a task is dequeued and re-enqueued on a different rq between scx_bpf_dsq_insert() and finish_dispatch(), the new QUEUED instance can end up with the same qseq as the old one: CPU X CPU Z ----- ----- enqueue p on rq A, qseq = N ops.dispatch() scx_bpf_dsq_insert(p) records qseq N sched_setaffinity(p) dequeue p from rq A enqueue p on rq B, qseq = N finish_dispatch(p, N) qseq matches, p is claimed The claim itself is still atomic so the core stays consistent, but an insert issued for a previous QUEUED instance gets applied to a new one which the BPF scheduler has just received through ops.enqueue(). This breaks the guarantee that dispatches targeting a stale instance are ignored. Generate qseq from a per-task counter, p->scx.ops_qseq, instead so that consecutive QUEUED instances of a task never share a qseq regardless of which rq they're on. The counter is only updated in scx_do_enqueue_task() with the task's rq locked, so no additional synchronization is needed, and it fits in an existing hole in struct sched_ext_entity on 64bit. Remove the now unused rq->scx.ops_qseq. Never generate qseq 0. NONE and DISPATCHING don't carry a qseq, so scx_bpf_dsq_insert() on a task in either state records 0. With a per-task counter, every task's first QUEUED instance would otherwise get qseq 0 and could be claimed by such an insert. Wrap the counter where the QSEQ field wraps so that it can't reach a value that shifts to 0 on 32bit either. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch Signed-off-by: Tejun Heo (cherry picked from commit e6ac89b8b1c12e9104df45a14a26e2dfa96ded06) [ jpiecuch: code lives in kernel/sched/ext.c and do_enqueue_task(); adjust struct/dump line context, name scx_bpf_dispatch() in the new comment ] Signed-off-by: Kuba Piecuch Signed-off-by: Sasha Levin commit 0a280732e0ec9da8c8cc1e1f5f0e9f5d42c9ed12 Author: Adrian Betschart Date: Mon Oct 12 18:05:21 2026 +0200 drm/amd/display: Don't replace a sink mode that shares the native totals commit 54c998c55fc9cbc391b350d67b86e0c2a0748f1a upstream. decide_crtc_timing_for_drm_display_mode() copies the native mode's CRTC timing into the requested mode when clock, htotal and vtotal match. That is meant for the modes amdgpu inserts itself: amdgpu_dm_create_common_mode() duplicates the native mode and changes only hdisplay and vdisplay, so those are sent with the native timing and scaled. A sink can also offer a real mode with the same clock and totals as its native mode. CTA-861 VIC 102 (4096x2160@60) and VIC 97 (3840x2160@60) both use 594 MHz and 4400x2250. With 3840x2160@60 as the preferred mode, a 4096x2160@60 request goes out with the 3840x2160 timing and the framebuffer scaled into it (dst 3840x2025 at y=67), while the AVI InfoFrame still carries VIC 102. A JVC projector then reports 3840x2160 and shows a corrupted right edge. 4096x2160@24, whose totals differ, is sent and displayed correctly. Inserted modes keep the native sync positions; a real mode with its own active width does not. Compare those too, so only inserted modes are patched. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Adrian Betschart Assisted-by: Claude-Code:claude-opus-5-5 Tested-by: Dan Wheeler Reviewed-by: Roman Li Signed-off-by: Alex Deucher (cherry picked from commit 22f9a2da101c37f821cd00954f81dc598754f4d5) Cc: stable@vger.kernel.org (cherry picked from commit 54c998c55fc9cbc391b350d67b86e0c2a0748f1a) [ Adrian: this tree keeps the function in amdgpu_dm.c, with the equal-totals case as its own else-if; added the sync checks there. Dropped the KUnit test, its file does not exist here. ] Signed-off-by: Adrian Betschart Assisted-by: Claude-Code:claude-opus-5-5 Signed-off-by: Sasha Levin commit 59e4819227fdc4ef9920fce7a0b6f4e0124969c2 Author: Oliver Hartkopp Date: Tue Oct 13 09:43:06 2026 +0200 can: fix unique skb identifier regression under RPS commit 7093c3b8314a4ef7405c4066a2521398c455efe7 upstream. Commit d4fb6514ff8e ("can: use skb hash instead of private variable in headroom") moved the per-skb unique identifier used for raw_rcv() duplicate detection into skb->hash. With RPS enabled, get_rps_cpu() calls skb_get_hash() before the frame reaches the CAN subsystem. Since CAN skbs have no L3/L4 headers, the flow dissector assigns every CAN frame the same non-zero software hash. can_set_skb_uid() only generated a new identifier when skb->hash was 0, so it kept this constant hash. When the SLAB allocator later reused the same skb address, raw_rcv() mistook the next legitimate frame for a duplicate and dropped it. Fix this by storing the CAN UID in the CAN skb extension (struct can_skb_ext::can_skb_uid) instead of skb->hash, decoupling it from any hash the network stack may compute. can_set_skb_uid() keeps its "assign only if unset" behaviour, which preserves UIDs set before transmission (e.g. by isotp to identify echo frames) across the local loopback path. Frames whose extension is shared with another clone (e.g. via tc mirred or netem duplicate) are given a private extension copy before the UID is assigned, so that independently received skb clones from real CAN interfaces (skbcnt = 0) don't end up with the same UID. The limitation that tc mirred/netem skb duplicates might be dropped in raw_rcv for looped back isotp echo frame skbs is accepted. There is no valid use-case for tc mirred or netem together with isotp which is not capable to operate on different CAN interfaces simultaneously. For routing and modifying CAN frames together with isotp use can-gw. can-gw and vxcan additionally clear the UID of forwarded/duplicated frames so each newly routed frame gets its own unique identifier. [ backport to 6.12: no CAN skb extensions available, so the UID is kept in struct can_skb_priv::skbcnt in the headroom (effectively reverting d4fb6514ff8e) and isotp is adapted accordingly. As skb clones share the headroom, the private extension copy for tc mirred/netem duplicates is not applicable. The UID resets in can-gw and vxcan are omitted, as writing to the shared headroom of cloned skbs would also alter the UID of the original skb. This keeps the pre-d4fb6514ff8e behaviour for routed and vxcan forwarded frames. ] Fixes: d4fb6514ff8e ("can: use skb hash instead of private variable in headroom") Reported-by: Joerg Willmann Closes: https://lore.kernel.org/linux-can/2859AD3D-C805-41A0-9036-C5E8EE152419@clnt.de/ Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit e454ec553996f21085657c96c8a605e2d89a81a6 Author: Cristian Papa Date: Mon Oct 12 11:42:31 2026 -0300 wifi: mt76: mt7603: initialize global station WCID commit 456de496b53ae73e6e3020fec815dbdc88aa7c07 upstream. mt7603 uses a driver-private global station WCID for frames that have neither a station nor a vif, including frames injected through a monitor interface. Unlike the core global WCID initialized by mt76_register_device(), this WCID is published without ever being passed to mt76_wcid_init(). Since commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status"), mt76_tx() queues every such frame on the WCID's tx_pending or tx_offchannel queue and links its tx_list. The first injected frame therefore reaches __skb_queue_tail() with an uninitialized sk_buff_head and dereferences a NULL prev pointer. Initialize the WCID before publishing it. The fix was tested on an MT7603 PCIe device. Three wildcard probe requests were injected through a monitor interface. The hardware queue head and tail advanced from 0 to 3 and a second radio captured the third request over the air. No oops or reset occurred. After restoring AP mode, a 150 MB transfer also completed without a reset. Fixes: 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status") Cc: stable@vger.kernel.org Signed-off-by: Cristian Papa Link: https://patch.msgid.link/20260904010702.16306-1-pcristian292@gmail.com Signed-off-by: Felix Fietkau [ mt76_wcid_init() takes no band index in this tree; drop the argument. ] Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Cristian Papa Signed-off-by: Sasha Levin commit ed250c60e164a8d0b00bd1183227cbf93997f5b6 Author: Adrian Bente Date: Thu May 28 10:08:51 2026 +0300 netfilter: flowtable: fix offloaded ct timeout never being extended commit 53b3e60edb674b442b2b3bbdba484667b0f47a5d upstream. OpenWrt has recently migrated many platforms to kernel 6.18. On the MediaTek platform, which supports hardware network offloading, WiFi connections accelerated via the WED path were observed to drop after roughly 300 seconds. After several debugging sessions, assisted by the Claude LLM, the problem was narrowed down as follows: nf_flow_table_extend_ct_timeout() extends ct->timeout for offloaded flows using: cmpxchg(&ct->timeout, expires, new_timeout); 'expires' comes from nf_ct_expires(ct) and is a relative value, while ct->timeout holds an absolute timestamp. The two are never equal, so the cmpxchg always fails and the timeout is never extended. This goes unnoticed for most flows, but a long-lived hardware (WED) offloaded flow on MediaTek MT7986 eventually has ct->timeout decay to zero, the conntrack entry is reaped and the connection breaks. Open-code the relative value from a single READ_ONCE(ct->timeout) snapshot and compare against that same absolute snapshot in the cmpxchg, so the timeout extension actually takes effect while the datapath remains authoritative if it updates ct->timeout concurrently. Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout extension logic") Cc: stable@vger.kernel.org Suggested-by: Florian Westphal Signed-off-by: Adrian Bente Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit c7ff8301a4bee8b227b8b9697c27781a67f26a5c Author: Florian Westphal Date: Tue Apr 15 15:53:48 2025 +0200 netfilter: conntrack: fix erronous removal of offload bit commit d2d31ea8cd80b9830cdab624e94f9d41178fc99d upstream. The blamed commit exposes a possible issue with flow_offload_teardown(): We might remove the offload bit of a conntrack entry that has been offloaded again. 1. conntrack entry c1 is offloaded via flow f1 (f1->ct == c1). 2. f1 times out and is pushed back to slowpath, c1 offload bit is removed. Due to bug, f1 is not unlinked from rhashtable right away. 3. a new packet arrives for the flow and re-offload is triggered, i.e. f2->ct == c1. This is because lookup in flowtable skip entries with teardown bit set. 4. Next flowtable gc cycle finds f1 again 5. flow_offload_teardown() is called again for f1 and c1 offload bit is removed again, even though we have f2 referencing the same entry. This is harmless, but clearly not correct. Fix the bug that exposes this: set 'teardown = true' to have the gc callback unlink the flowtable entry from the table right away instead of the unintentional defer to the next round. Also prevent flow_offload_teardown() from fixing up the ct state more than once: We could also be called from the data path or a notifier, not only from the flowtable gc callback. NF_FLOW_TEARDOWN can never be unset, so we can use it as synchronization point: if we observe did not see a 0 -> 1 transition, then another CPU is already doing the ct state fixups for us. Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout extension logic") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 3d1d3cd8026652f8c17586f8acdef11c3c595286 Author: Jens Axboe Date: Mon Jan 19 19:46:26 2026 -0700 io_uring/waitid: fix KCSAN warning on io_waitid->head Commit b994ace83a2bc7699420f6a4c6b860c8da133159 upstream. Storing of the iw->head entry inside the wait_queue callback, or when removing a waitid item, really should use proper load/store acquire/release semantics, and KCSAN correctly warns of that. Ensure that they do so. Reported-by: syzbot+eb441775f4f948a0902f@syzkaller.appspotmail.com Fixes: a48c0cbf28c0 ("io_uring/waitid: have io_waitid_complete() remove wait queue entry") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 09951a4d37e33b0197afc7fb77e39f09a3213ee6 Author: Jens Axboe Date: Thu Oct 9 10:55:08 2025 -0600 io_uring/waitid: use io_waitid_remove_wq() consistently Commit ab673c1bcaf20ac70352eeb6bf5b828462676693 upstream. Use it everywhere that the wait_queue_entry is removed from the head, and be a bit more cautious in zeroing out iw->head whenever the entry is removed from the list. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4487cf79bf173f2b426a02d102076f8a20d23b96 Author: Osama Abdelkader Date: Tue Aug 4 18:00:47 2026 +0200 drm/panthor: validate userspace queue count against initialized firmware slot count commit ec86c43dcfff68eab4db9bdafcd3e2b16e342e18 upstream. In panthor_drv.c:panthor_ioctl_group_create(), the queue count is validated against the hardcoded maximum: if (!args->queues.count || args->queues.count > MAX_CS_PER_CSG) return -EINVAL; However, if the firmware reports fewer slots than MAX_CS_PER_CSG, panthor_fw_init_ifaces() will only initialize that smaller number of stream interfaces. If unprivileged userspace requests more queues than the firmware reported (but no more than MAX_CS_PER_CSG), cs_slot_prog_locked() fetches an uninitialized stream interface and may crash when dereferencing cs_iface->input->ringbuf_base. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260803141149.68182-1-osama.abdelkader@gmail.com?part=1 Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20260804160048.174148-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price Signed-off-by: Liviu Dudau Signed-off-by: Greg Kroah-Hartman commit de18bd11324518af67f8f5a4a903b9b208652fb2 Author: Maíra Canal Date: Wed Sep 30 15:20:44 2026 -0300 drm/vc4: Fix binner slot allocation failing on an idle GPU [ Upstream commit cca01232d94adcb10f7c8c5bb8ce072b045fcb58 ] A job's binner slots are returned to bin_alloc_used by vc4_complete_exec(), which runs from the job_done workqueue, but the seqno vc4_v3d_get_bin_slot() waits on is incremented earlier, in the function vc4_irq_finish_render_job(). Therefore, a waiter can wake, retry, and still find the pool full because the worker has not run. By then, the job might have left the render_job_list, so no seqno remains to wait on and the allocation fails returning -ENOMEM. This scenario can be reproduced on a Raspberry Pi 3 by using a burst of small jobs (e.g. Piglit's `quick_gl` suite), with userspace seeing a rejected submit for a pool about to become free. Note that the slots are held from validation until the render completes, so the pool can also be exhausted by jobs still queued on bin_job_list, leaving render_job_list empty and nothing to wait on. Release the slots from the FRDONE handler and wait on the pool instead of on one job's seqno. This bounds the wait to the actual resource. Also, by claiming the slot inside the wait condition, another submit is unable to take the slot between the wakeup and the retry. vc4_complete_exec() keeps clearing the slots for jobs that never completed, and now wakes the waiters too. Note that the wait takes a deadline, since the two callers need different ones. The submit path is a user task and can be interrupted, so it waits without one. On the other hand, vc4_overflow_mem_work() runs on a worker and never sees a signal, so it needs a deadline. During a reset, vc4_irq_disable() masks V3D_DRIVER_IRQS before draining the worker, and with those masked nothing can release a slot. This deadlocks: the worker would wait for slots that only the reset can free, while the reset waits in cancel_work_sync() for the worker. Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260930182204.1877361-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 77b40223f712cf947ca848beb51740ddb24f1707 Author: Maxime Ripard Date: Fri Jun 21 16:20:45 2024 +0100 drm/vc4: Make v3d paths unavailable on any generation newer than vc4 [ Upstream commit dbe8ef676f2764f132d2467882e01e313eef495a ] The V3D IP has been separate since BCM2711, so let's make sure we issue a WARN if we're running not only on BCM2711, but also anything newer. Signed-off-by: Maxime Ripard Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-22-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson Stable-dep-of: cca01232d94a ("drm/vc4: Fix binner slot allocation failing on an idle GPU") Signed-off-by: Sasha Levin commit 0f8e2b2045355a0ee2008125e573435504b13cee Author: Ilia Gavrilov Date: Thu Oct 8 14:41:17 2026 +0000 vsock: Fix memory leak in vmci_transport_recv_dgram_cb() [ Upstream commit 7c24a4e87e219072e5e106f6791146cbf3b056b3 ] During the closure of a datagram socket, the vmci_transport_recv_dgram_cb() function may be called, which will add the packets to the socket's backlog; then, after the receive queue is cleared, the __release_sock() function will move the packet back from the socket's backlog to the receive queue, which will lead to a memory leak. sock_close __sock_release __vsock_release // take ownership by user-space lock_sock_nested sock_set_flag(sk, SOCK_DEAD) vmci_transport_release vmci_dispatch_dgs vmci_datagram_invoke_guest_handler vmci_transport_recv_dgram_cb sk_receive_skb if (!sock_owned_by_user(sk)) [...] (!) else if sk_add_backlog() [...] (!) skb_queue_purge(&sk->sk_receive_queue) release_sock __release_sock // move all packets from the backlog // to the receive queue (!) sk_backlog_rcv vsock_queue_rcv_skb [...] __sock_queue_rcv_skb if (!sock_flag(sk, SOCK_DEAD)) // Since the socket is "dead", the function will not // be called sk->sk_data_ready(sk) sock_release_ownership(sk); sock_put Add a receive queue cleanup in the socket destructor to fix this. syzkaller report: unreferenced object 0xffff8880117bfb80 (size 240): comm "irq/56-vmw_vmci", pid 205, jiffies 4295064448 (age 73.992s) hex dump (first 32 bytes): 78 dc 26 1e 80 88 ff ff 78 dc 26 1e 80 88 ff ff x.&.....x.&..... 00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff ..........&..... backtrace: [] __alloc_skb+0x287/0x330 net/core/skbuff.c:505 [] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport] [] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci] [] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci] [] vmci_interrupt+0x55/0x290 [vmw_vmci] [] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205 [] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314 [] kthread+0x2e6/0x3a0 kernel/kthread.c:376 [] ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reviewed-by: Stefano Garzarella Signed-off-by: Ilia Gavrilov Link: https://patch.msgid.link/20261008144046.90853-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6774af7cd17be8f0d0f70de3a749d381b4f2e9da Author: Fernando Fernandez Mancera Date: Thu Oct 8 12:41:35 2026 +0200 net: openvswitch: validate transport header presence in set_ipv6_addr [ Upstream commit 3c6a4b11330fe424557538a98fca9f0a4c5bf313 ] When executing IPv6 address rewrite actions on IPv6 fragments, set_ipv6_addr() calls update_ipv6_checksum(). If parse_ipv6hdr() processes a non-first IPv6 fragment, it sets key->ip.proto to NEXTHDR_FRAGMENT and returns early without calling skb_set_transport_header(). update_ipv6_checksum() unconditionally evaluates skb_transport_offset() on entry before checking l4_proto. Because skb->transport_header is uninitialized, this triggers a warning under CONFIG_DEBUG_NET=y although it is completely harmless. Fix this by returning early in update_ipv6_checksum() if l4_proto is NEXTHDR_FRAGMENT. This avoids reading the uninitialized transport offset for fragments while preserving the debug warning for any other protocol where the transport header is unexpectedly missing. See the syzbot trace: !skb_transport_header_was_set(skb) WARNING: ./include/linux/skbuff.h:3075 at skb_transport_header include/linux/skbuff.h:3075 [inline], CPU#1: syz-executor463/5635 WARNING: ./include/linux/skbuff.h:3075 at skb_transport_offset include/linux/skbuff.h:3250 [inline], CPU#1: syz-executor463/5635 WARNING: ./include/linux/skbuff.h:3075 at update_ipv6_checksum net/openvswitch/actions.c:361 [inline], CPU#1: syz-executor463/5635 WARNING: ./include/linux/skbuff.h:3075 at set_ipv6_addr+0x462/0x660 net/openvswitch/actions.c:399, CPU#1: syz-executor463/5635 [...] RIP: 0010:skb_transport_header include/linux/skbuff.h:3075 [inline] RIP: 0010:skb_transport_offset include/linux/skbuff.h:3250 [inline] RIP: 0010:update_ipv6_checksum net/openvswitch/actions.c:361 [inline] RIP: 0010:set_ipv6_addr+0x462/0x660 net/openvswitch/actions.c:399 [...] Call Trace: set_ipv6 net/openvswitch/actions.c:531 [inline] do_execute_actions+0x557e/0x8600 net/openvswitch/actions.c:1366 ovs_execute_actions+0xde/0x520 net/openvswitch/actions.c:1592 ovs_packet_cmd_execute+0xb4f/0xf10 net/openvswitch/datapath.c:705 genl_family_rcv_msg_doit+0x233/0x340 net/netlink/genetlink.c:1114 genl_rcv_msg+0x614/0x7a0 net/netlink/genetlink.c:1209 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2572 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218 netlink_unicast+0x7bd/0x940 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec+0x14e/0x190 net/socket.c:800 Reported-by: syzbot+4cc63fcfb3845e149969@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4cc63fcfb3845e149969 Fixes: 3fdbd1ce11e5 ("openvswitch: add ipv6 'set' action") Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20261008104135.4722-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2beb5de57626110fa11260d014115b200b3ad22 Author: Vadim Fedorenko Date: Wed Oct 7 20:33:59 2026 +0000 ptp: ocp: fix PCIe delay estimation calculation [ Upstream commit f8c8bd159a9bf626dd4921b7746ff481fce8c758 ] The commit in fixes introduced a high cap for delayas U64_MAX value while ktime_t is actually s64. This is wrong cap as it becomes negative value and any comparison to a real delay will fail to update delay value. Use KTIME_MAX constant as correct max cap for PCIe delay. The issue was hit in production (a negative value is observed): # cat /sys/class/timecard/ocp0/ts_window_adjust -3 Fixes: aa05fe67bcd64 ("ptp: ocp: Improve PCIe delay estimation") Signed-off-by: Vadim Fedorenko Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261007203359.417270-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c8e934287debb29c6ded86b21e49fc72e186d15e Author: Petr Machata Date: Tue Oct 6 16:21:28 2026 +0200 mlxsw: spectrum_flower: Fix port range register leak in tmplt_create() [ Upstream commit 7ea07afb230f1342ab0f9365edd0aae137f425d3 ] mlxsw_sp_flower_tmplt_create() parses a flow_cls_offload template into a stack-local struct mlxsw_sp_acl_rule_info purely to compute rulei.values.elusage. Parsing can acquire port range registers via mlxsw_sp_flower_parse_ports_range(), but since this rulei never goes through mlxsw_sp_acl_rulei_destroy(), those registers were never released, including through chain template deletion. Factor out of mlxsw_sp_acl_rulei_destroy() the code to actually release the necessary resources and call from mlxsw_sp_flower_tmplt_create() to plug the leak. The issue was found during a review of Wentao Liang's patch referenced below. Fixes: fe22f7410527 ("mlxsw: spectrum_flower: Add ability to match on port ranges") Reported-by: Wentao Liang Closes: https://lore.kernel.org/netdev/20260917113236.2149095-1-vulab@iscas.ac.cn/ Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Reviewed-by: Jacob Keller Link: https://patch.msgid.link/95339cf970ce78e1a74aa86ffcc104ecf7c7762c.1791294384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a1867065299e7c6f0eb1fe6b93fa1d09e8d6a1a9 Author: Li RongQing Date: Tue Oct 6 13:58:20 2026 +0300 net/mlx5e: Order ICOSQ cc update after CQ doorbell [ Upstream commit b056ca4d3742d0769f91137bb1ce3215428398f7 ] mlx5e_poll_ico_cq() requires sq->cc to be updated only after mlx5_cqwq_update_db_record(), otherwise a CQ overrun may occur. The current implementation updates sq->cc before the CQ doorbell record, violating this ordering requirement. Update the CQ doorbell record first and use dma_wmb() before updating sq->cc. This ensures that the CQ space is released to the device before the corresponding ICOSQ consumer index is updated by software. Fixes: fd9b4be8002c ("net/mlx5e: RX, Support multiple outstanding UMR posts") Signed-off-by: Li RongQing Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261006105820.257208-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a6f79eab6e2cae47d327750a6563a103d40aeae Author: Tianyi Gao Date: Tue Oct 6 18:32:36 2026 +0100 veth: fix peer NETDEV_XDP_ACT_NDO_XMIT after GRO is toggled while down [ Upstream commit 3f090039995f609a8e236f37980dee5712dded61 ] A veth device advertises NETDEV_XDP_ACT_NDO_XMIT only if its peer has an XDP program attached or GRO enabled, that is, only if the peer will have NAPI to receive the frames. veth_set_features() updates the peer's flag when GRO is toggled, but returns early if the device is down, and veth_open() only refreshes the flags of the device being opened. Toggling GRO while the device is down therefore leaves the peer's flag stale after the device comes up. If GRO was enabled while down, the device comes up with NAPI but the peer does not advertise NDO_XMIT, and devmap rejects redirects to the peer with -EOPNOTSUPP. If GRO was disabled while down, the device comes up without NAPI but the peer still advertises NDO_XMIT, so redirects are accepted and then dropped in veth_xdp_xmit() with -ENXIO. Commit 7a6102aa6df0 ("veth: Update XDP feature set when bringing up device") made veth_open() refresh the device's own flags. Refresh the peer's flags there too. The peer's flag depends on this device's XDP program and GRO setting, not on whether the peer is up, so it is correct to set it even if the peer is down. Fixes: 8267fc71abb2 ("veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features flag") Signed-off-by: Tianyi Gao Reviewed-by: Toke Høiland-Jørgensen Acked-by: Jesper Dangaard Brouer Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20261006173241.65945-2-tianyi@cloudflare.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 521cf8403a185a9d5790fe324bb43ba7ea85f51c Author: Gyeyoung Baek Date: Thu Oct 1 22:39:12 2026 +0900 drm/imagination: Fix reference and vm_bo handling in remap() [ Upstream commit 196d4d10c1b33ae176685ff42a9994a5952b1d0f ] When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap() splits the mapping into prev/next parts covering what the request did not take, instead of creating something new. It gets two things wrong. - A GEM reference is taken for each part but it's never needed and never dropped, so it leaks one reference per split (remap-next-in-2m in tests/imagination/pvr_vm_map.c): CRITICAL: 33558528 bytes of shmem still held after close - The parts still belong to the original object being split, but pvr_vm_gpuva_remap() links them to ctx->gpuvm_bo, the new object's vm_bo: prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo) \___________link___________/ (mismatch: BO_A != BO_B) drm_gpuva_link() catches the mismatch: WARNING: drivers/gpu/drm/drm_gpuvm.c:2108 at drm_gpuva_link+0x2ec/0x310 drm_WARN_ON(obj != vm_bo->obj) Call trace: drm_gpuva_link pvr_vm_gpuva_remap __drm_gpuvm_sm_map pvr_vm_map pvr_ioctl_vm_map Link them to op->remap.unmap->va->vm_bo instead. The locking of the GPUVA lists of the other objects touched by a split is not addressed here; it is handled by switching the GPUVM to immediate mode. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Gyeyoung Baek Reviewed-by: Brajesh Gupta Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-1-f58254e5dfb8@gmail.com Signed-off-by: Alessio Belle Signed-off-by: Sasha Levin commit 3fb5ad2951a6df92c98f4f06cd70f20c50a2eb2a Author: Eric Dumazet Date: Wed Oct 7 06:56:15 2026 +0200 flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect() [ Upstream commit f202578efc738b883cfa04889eb97328914265a7 ] bpf_flow_dissect() sanitizes the offsets returned by the BPF program with clamp_t(u16, ..., hlen). If hlen is bigger than 65535, the upper bound is truncated before the comparison. For instance, with hlen == 65536, both nhoff and thoff are forced to zero, even if the program returned sane values. This is the same class of bug as the one fixed in commit 99bda1ecbd56 ("flow_dissector: avoid u16 truncation of skb->len when computing thoff"). That fix does not cover the BPF path, because __skb_flow_dissect() returns early when a BPF flow dissector handles the packet. struct bpf_flow_keys stores nhoff and thoff as u16, so cap hlen to U16_MAX before clamping. Found by sashiko while reviewing the commit above. Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20261007045616.445596-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eec08044bc7e96399006549f846aa1174e20fd8a Author: Michael Chan Date: Mon Oct 5 13:42:45 2026 -0700 bnxt_en: Fix driver init in kdump kernel [ Upstream commit 386f887c8290f0747dd0180e98ec7a82811bc506 ] Fix and strengthen the FLR sequence when initializing in the kdump kernel. If the NIC is behind a PCIe switch in synthetic (smart) mode, the switch may need to see that the BARs have been initialized before it will pass mem read/write TLPs to the NIC. On a Dell system with a PEX89144 PCIe switch, echo c > /proc/sysrq-trigger will trigger fatal AER without this patch: bnxt_en 0000:67:00.0: enabling device (0000 -> 0002) [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: fatal [Hardware Error]: section_type: PCIe error [Hardware Error]: port_type: 5, upstream switch port ... Add a new bnxt_kdump_reset() to do the expanded FLR sequence in the kdump kernel. We now disable bus master and memory, save the PCI state, do the FLR, clear the BARs, and restore the PCI state. The BARs have to be cleared to ensure that they get re-initialized and visible to the PCIe switch. Since it is the kdump kernel, we make every effort to continue in the best possible way even if pci_save_state() or pcie_flr() returns error. After FLR, we poll for an additional 5 seconds before aborting in case the device is not properly returning CRS. This is similar to the 5-second wait in bnxt_io_slot_reset(). Fixes: 8743db4a9acf ("bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs.") Reviewed-by: Kalesh AP Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20261005204246.3822563-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b190e8c9bdbd418e1fcee56a35c9de875891f27c Author: Michael Chan Date: Mon Oct 5 13:42:44 2026 -0700 bnxt_en: Add bnxt_clear_bars() helper [ Upstream commit 8f5d59b9cfa69beab3b52cca621bb301c5af98aa ] In bnxt_io_slot_reset(), we clear the 6 BAR registers. Add a helper function to do that. The helper will be used again in the next patch. Reviewed-by: Kalesh AP Reviewed-by: Somnath Kotur Reviewed-by: Joe Damato Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20261005204246.3822563-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 386f887c8290 ("bnxt_en: Fix driver init in kdump kernel") Signed-off-by: Sasha Levin commit 3192a5e398c64d48aad64a09e29643e327369bc4 Author: Haishuang Yan Date: Wed Sep 30 20:48:18 2026 +0800 pfcp: make sure the SEID is linear before reading it [ Upstream commit 23609bce9e1de525d1d0e73fc68c6e7971d0b49e ] pfcp_encap_recv() only makes sure that the UDP header and the 4 byte PFCP header are in the linear area. When the S flag is set, pfcp_session_recv() then reads the 8 byte SEID that follows, which is not covered by the pskb_may_pull() check. A short PFCP packet with the S flag set, or one whose session header lies in a fragment, therefore makes pfcp_session_recv() read beyond the end of the packet data, and whatever it finds there is stored in the tunnel metadata that flower later classifies on. Pull up to the end of the SEID before reading it, and drop packets that are too short to contain it. Reload the header pointer afterwards since pskb_may_pull() may reallocate the skb head. Use offsetofend() rather than sizeof(struct pfcphdr_session): the structure is not packed, so its size is 16 bytes because of the alignment of the __be64 member, while the header on the wire is only 12 bytes, and valid session messages would be dropped. Fixes: 6dd514f48110 ("pfcp: always set pfcp metadata") Signed-off-by: Haishuang Yan Link: https://patch.msgid.link/20260930124818.114224-3-yanhaishuang@cmss.chinamobile.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63d2801ba6cb9099e5c67342d11475cded9cf605 Author: Victor Nogueira Date: Thu Oct 1 12:32:00 2026 -0300 net/sched: cls_route: reject change with no routing attribute [ Upstream commit b72e025ac556984766392001e74b7587e145bcd0 ] route4_change on a filter change that supplies no routing attribute at all (no to/from/iif) reaches route4_set_parms with fold set, so the handle-mismatch check -- which only fires when creating -- is skipped. nhandle is built as the all-wildcard bucket (0x8000 | 0xFFFF << 16) and the filter is rekeyed to 0xFFFF8000, so the handle userspace already stored no longer addresses the filter. (The netlink reply carries the new handle; what goes stale is the handle the caller holds.) The rekey actually misclassifies the packets. The new handle's from_hash is the wildcard chain (route4_hash_wild), whose filters route4_classify applies without any id/iif comparison, and its bucket (256) is reached by every packet through the h < 256 restart. A filter that matched only a specific realm therefore becomes an unconditional catch-all that applies its classid and actions to all otherwise-unmatched traffic. Reject a change that would rekey the filter this way, with the routing-attributes-required error. A change that names at least one of to/from/iif, and an in-place replace that keeps the routing identity via a supplied attribute, are unaffected. A change of a filter that already sits at the wildcard handle is a metadata-only update and remains valid, so only a change that actually moves the handle is rejected. This is a follow-up to commit 41e85e54e564 ("net/sched: cls_route: Fix in-place replace"); this patch closes the no-routing-attribute variant that the parent series did not address. Conditions to recreate the bug: tc qdisc add dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route classid 1:2 tc filter show dev lo ingress # handle became 0xffff8000; iproute2's # stored 0x10001 no longer addresses it A change of a filter already at the wildcard handle, e.g. one created by "tc filter add dev lo ingress protocol ip pref 100 route classid 1:1" (iproute2 defaults the handle to 0xffff8000), stays a valid metadata-only update. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260907192133.2639067-1-victor@mojatatu.com Reviewed-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-0JB3.v1.20260929143022@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c7830e0120e6e1f5084212fd5b79b3092496f87 Author: Haishuang Yan Date: Thu Oct 1 12:22:32 2026 +0800 devlink: fix devlink_rel reference leak when notify work is pending [ Upstream commit c5381ae1cd1481cc431c2bd79460472c6f1d3ce3 ] devlink_rel_nested_in_notify_work_schedule() takes a reference on the devlink_rel for the notify work and then queues the work, ignoring the return value of schedule_delayed_work(). If the work is already pending, nothing new is queued, the work runs only once and drops only one reference, so the extra one is leaked together with the devlink_rel and its index in devlink_rels. This is easy to hit. devl_register() of a nested instance queues the work, and if the instance is unregistered before the work has run, devlink_rel_put() queues it again while it is still pending. The work also keeps rescheduling itself for as long as the parent devlink lock cannot be taken, which widens the window. Registering and unregistering a nested devlink instance 100 times while holding the parent lock leaks all 100 devlink_rel objects. The reschedule path in devlink_rel_nested_in_notify_work() has the same problem: if the work was queued again while it was running, the reference it holds is never dropped. Drop the reference in both places when the work was already pending. The pending work holds its own reference, so this can not be the last one. Fixes: c137743bce02 ("devlink: introduce object and nested devlink relationship infra") Signed-off-by: Haishuang Yan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261001042232.222987-1-yanhaishuang@cmss.chinamobile.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 50d0cd575cab763f833d6ac6eb6550b23a0b3dae Author: Eric Dumazet Date: Thu Oct 1 19:11:38 2026 +0000 flow_dissector: avoid u16 truncation of skb->len when computing thoff [ Upstream commit 99bda1ecbd56905f8bd934b9cdccd3bd251192b1 ] __skb_flow_dissect() computes key_control->thoff using: key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); min_t(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skb_probe_transport_header() point the transport header inside the Ethernet header. Such skbs are not exotic: - At the time of commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET with PACKET_VNET_HDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and alloc_skb_with_frags() accepted up to MAX_SKB_FRAGS (17) order-0 pages on top of the linear part). - BIG TCP now makes skbs larger than 64KB common. - The following patch makes tun_get_user() dissect IFF_TAP frames before eth_type_trans() pulls the Ethernet header, so a GSO frame carrying a 65522..65535 byte L3 packet will be dissected with skb->len in [65536, 65549]. Compare as u32 instead. If the resulting offset cannot be represented in the u16 key_control->thoff, cap it to U16_MAX and report the dissection as failed rather than silently returning a wrong transport offset. thoff is still set on failure, as some callers (such as eth_get_headlen()) use it regardless of the return value. Fixes: d0c081b49137 ("flow_dissector: properly cap thoff field") Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20261001191140.2818991-2-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93ea8704505f73d2d9909c31a3dc7baebb8444d6 Author: Waiman Long Date: Mon Oct 5 06:43:10 2026 -0400 cgroup/cpuset: Call is_in_v2_mode() after acquiring cpuset_mutex in cpuset_handle_hotplug() [ Upstream commit b8eb5fd5bdb4c03758b056c70e5e1d962ca89757 ] It is reported by sashiko that calling is_in_v2_mode() outside of cpuset_mutex critical section in cpuset_handle_hotplug() can introduce a TOCTOU race where cgroup hierarchy may have changed from v1 to v2 or vice versa after is_in_v2_mode() is called leading to erroneously skip the allocation of tmpmasks or incorrectly modify cpus_allowed masks, resulting in cpuset state corruption. Fix that by calling is_in_v2_mode() after acquiring the cpuset_mutex. Fixes: b8d1b8ee93df ("cpuset: Allow v2 behavior in v1 cgroup") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit a8bf7587603602f9468a5ec26400523e158bebbc Author: Chen Ridong Date: Mon Aug 25 03:23:51 2025 +0000 cpuset: separate tmpmasks and cpuset allocation logic [ Upstream commit ada00d51622822b151e1b8cc2bc85a20d2191349 ] The original alloc_cpumasks() served dual purposes: allocating cpumasks for both temporary masks (tmpmasks) and cpuset structures. This patch: 1. Decouples these allocation paths for better code clarity 2. Introduces dedicated alloc_tmpmasks() and dup_or_alloc_cpuset() functions 3. Maintains symmetric pairing: - alloc_tmpmasks() ↔ free_tmpmasks() - dup_or_alloc_cpuset() ↔ free_cpuset() Signed-off-by: Chen Ridong Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Stable-dep-of: b8eb5fd5bdb4 ("cgroup/cpuset: Call is_in_v2_mode() after acquiring cpuset_mutex in cpuset_handle_hotplug()") Signed-off-by: Sasha Levin commit 5dac6bf09b5a4fff2433629801309c3884c3e94a Author: Marek Szyprowski Date: Fri Oct 2 11:21:12 2026 +0200 ASoC: samsung: i2s: enable op_clk in probe to balance runtime PM [ Upstream commit 7529254014764ae0b8c33d5c61a58f36c65b1a1c ] The probe function puts the device into the runtime PM active state with only the "iis" bus clock enabled, but it also sets priv->op_clk to the parent of the RCLK_SRC mux without enabling it. The runtime PM suspend callback disables both clocks, so the first runtime suspend after probe disables op_clk once more than it was enabled. On Exynos5250 Arndale both clocks resolve to the same EXYNOS_I2S_BUS gate, so this triggers the following warning during boot: WARNING: drivers/clk/clk.c:1270 at clk_core_disable+0xe4/0x23c, CPU#0: kworker/u8:3/45 i2s_bus already disabled ... Workqueue: pm pm_runtime_work Call trace: ... clk_core_disable from clk_disable+0x28/0x34 clk_disable from i2s_runtime_suspend+0x58/0x68 [snd_soc_i2s] i2s_runtime_suspend [snd_soc_i2s] from genpd_runtime_suspend+0xc4/0x298 genpd_runtime_suspend from __rpm_callback+0x48/0x18c __rpm_callback from rpm_callback+0x4c/0x50 rpm_callback from rpm_suspend+0xf4/0x718 rpm_suspend from pm_runtime_work+0x9c/0xa0 ... Fix this by enabling op_clk in probe right after getting it, so the clock state matches the runtime PM active state, and by disabling it in remove. Fixes: 48279c53fd1d ("ASoC: samsung: i2s: Prevent external abort on exynos5433 I2S1 access") Assisted-by: Claude Opus 5.5 Signed-off-by: Marek Szyprowski Link: https://patch.msgid.link/20261002092116.585466-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8fa3be9f971c1a3c31d87ecc1a019a95859b6ad3 Author: Alvin Šipraga Date: Tue Oct 6 14:55:57 2026 +0200 ASoC: adau1372: fix invalid default state of output ASRC and DAC muxes [ Upstream commit 36d0e05815ce84266c8b138cd4f84c3feeaf15f4 ] The chip has strange power-on reset values for the registers that control the output ASRC and DAC source muxes - the values are actually marked "Reserved" in the datasheet [1]. This means that until the underlying kcontrols are modified, the codec will not function as expected. The registers in question are: register / field reset value valid values ASRCO_SOURCE_0_1 0x10 ASRC_OUT_SOURCE0 0 4 .. 16 ASRC_OUT_SOURCE1 1 4 .. 16 ASRCO_SOURCE_2_3 0x10 ASRC_OUT_SOURCE2 2 4 .. 16 ASRC_OUT_SOURCE3 3 4 .. 16 DAC_SOURCE_0_1 0x10 DAC_SOURCE_0 0 12 .. 13 DAC_SOURCE_1 1 12 .. 13 Set some sane defaults during the driver probe: ADC Decimator0 -> Output ASRC0 ADC Decimator1 -> Output ASRC1 ADC Decimator2 -> Output ASRC2 ADC Decimator3 -> Output ASRC3 Input ASRC0 -> DAC0 Input ASRC1 -> DAC1 With this, the chip will behave as advertised by the default kcontrol state exposed by the driver. [1] https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support") Signed-off-by: Alvin Šipraga Acked-by: Nuno Sá Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-2-599cc17fb5f6@analog.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6cf4c3c9b7a4df0fe4cc67481b7b251cff781b29 Author: Alvin Šipraga Date: Tue Oct 6 14:55:56 2026 +0200 ASoC: adau1372: allow sleepy powerdown GPIOs [ Upstream commit 64dd172bbffe6135d79a06ddad53dd2da4d8bd62 ] gpiod_set_value() emits a WARN when the GPIO provider indicates that it can sleep, as is typical for I2C controlled GPIO expanders. Since the powerdown GPIO is only manipulated in process context, use the _cansleep variant instead. This lets the driver use sleepy GPIOs to power off the chip. Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support") Signed-off-by: Alvin Šipraga Acked-by: Nuno Sá Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-1-599cc17fb5f6@analog.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3fe1cbe6f6135b5c8a9e2554da1b8f1c38ff6d04 Author: Devin Wittmayer Date: Fri Sep 4 18:35:51 2026 -0700 wifi: mt76: mt792x: pick the SAR table layout from the table itself [ Upstream commit af97bf5a7e72da9026de184676df8e2fa57e1058 ] The SAR power tables are parsed with a version byte from a different ACPI table, never their own. Some firmware declares version 1 and ships version 2 tables. The entries then start a byte early, and the 6 GHz limits the table carries are dropped, because the older layout has no room for them. ASUS GA503RM, MTCL declares v1: MTGS 28 bytes v1: (28-6) % 5 = 2, no fit v2: 3 tables MTDS 19 bytes v1: (19-6) % 6 = 1, no fit v2: 1 table The layouts accept disjoint lengths, so take whichever one fits and keep it per table. Reported-by: Sagun Kayastha Closes: https://github.com/morrownr/mt76/issues/62 Fixes: f965333e491e ("mt76: mt7921: introduce ACPI SAR support") Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260905013551.24635-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cdbd0327399a84ca53346dfda99f4a7e9ec42c04 Author: Junjie Cao Date: Thu Sep 10 09:23:00 2026 +0800 wifi: mt76: mt792x: treat 0xff ACPI SAR entries as no limit [ Upstream commit 45f53d98cbaa078907b6a300ff3974dfb5ae8776 ] Some ASUS firmware carries 0xff in MTGS power slots. The driver narrows the byte to s8, so the slot reads as -1 in its 0.5 dBm units, wins the min() against the regulatory limit and caps every rate the driver programs. On an ASUS Zenbook 14 UM3406HA (MT7922) all six MTGS tables hold 0xff in every power byte, and txpower_sku shows tmac 3 on every supported OFDM/HT/VHT/HE rate against EEPROM entries of 25-39, under both the FR and the world regulatory domain. Huy Nguyen Dinh Quang saw the same clamp on a Vivobook S 14 M5406WA, with 5 GHz TX at ~40 Mbps, and proposed skipping the geo entry. Skip a geo entry whose power byte is 0xff. The MTDS entry is narrowed the same way on its way into the geo lookup, so give it the same treatment, and clamp the dynamic value plus offset at 127 so a no-limit entry cannot wrap. Fixes: f965333e491e ("mt76: mt7921: introduce ACPI SAR support") Link: https://bugzilla.redhat.com/show_bug.cgi?id=2515420 Reported-by: Huy Nguyen Dinh Quang Closes: https://lore.kernel.org/linux-wireless/20260827134820.2607530-1-huynguyendinhquang@gmail.com/ Signed-off-by: Junjie Cao Tested-by: Cristian Fleischer Link: https://patch.msgid.link/acb947435fc78d5c06039c7bd5609c735468b0ee.1789002236.git.junjie.cao@intel.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 73721d0b07cbbe5c3ec272b7b6b169b11eda91cc Author: Devin Wittmayer Date: Thu Sep 10 19:44:28 2026 -0700 wifi: mt76: mt7925: don't put the band auto marker in TGID [ Upstream commit 5796b2bf9ff718342773ac760d86eb126c112a4f ] band_idx starts out as 0xff, which tells the firmware to pick the band on its own. A remain-on-channel grant normally writes a real index over it before anything else looks. Two cases never see that: an MLD station throws the grant away, and an AP has no association to trigger one. The TX descriptor reads the same field into a two-bit slot, so the marker comes out as 3. Every data frame from those two goes out tagged band 3. Beacons are fine, they reach the firmware separately and never build a descriptor. Same numbers on an MT7925 and on a Netgear A9000: stock patched station, one link 0x00000001 0x00000001 station, two links 0x00003001 0x00000001 AP 0x00003013 0x00000013 real band index, STA 0x00001001 0x00001001 real band index, AP 0x00001013 0x00001013 Only the marker cases move. Fixes: 0cb349d742d1 ("wifi: mt76: mt7925: update mt7925_mac_link_bss_add for MLO") Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260911024428.65244-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0281dac1e213329b053fb02e612de7f1477a52d7 Author: Nicolas Cavallari Date: Mon Aug 10 17:45:10 2026 +0200 wifi: mt76: mt7915: disable rx napi when removing device [ Upstream commit 916c484d29d82f45c281da2786fcd6a1284430ce ] Unloading the mt7915e module with a MT7916 triggers multiples WARN in __netif_napi_del_locked() and in page_pool_disable_direct_recycling() because the driver does not disable the napi before destroying it. This is troublesome since on MT7916 it is required to unload the module and reinsert it with a different enable_6ghz parameter to change the frequency. The system generally becomes unstable after reinserting the module. Fix it by disabling rx napi inside mt7915e itself, even through napi rx is enabled in the mt76 generic code. Disabling it in the mt76 generic code was previously attempted and reverted because napi was disabled too late and rx handlers could access freed structures. Note that the tx side is enabled and disabled by the mt76 generic code. It is disabled in mt7915_stop_hardware() since, unlike mt7915_unregister_device(), is it also called in the probe path if an error happens after rx napi is enabled. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Nicolas Cavallari Link: https://patch.msgid.link/20260810154923.32546-1-nicolas.cavallari@green-communications.fr Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b193f61dee09a6193be1b2d9c7447ce978f11d44 Author: Tao Gong Date: Sun Aug 23 05:37:39 2026 +0000 wifi: mt76: mt7996: fix struct mt7996_mcu_wed_rro_ba_delete_event layout [ Upstream commit 9c9e4e4c8b45873e53774ab8207825b37b7565ec ] Correct the definition of struct mt7996_mcu_wed_rro_ba_delete_event to match the 12-byte event record layout observed from firmware. The event TLV sent by firmware is 12 bytes in length rather than 8 bytes. It contains an additional 4 bytes that appear to be wlan_id and tid. For example, a captured batch deletion of sessions 8, 9, and 10 (TIDs 6, 0, and 1) shows: 00000000: 02 00 0c 00 08 00 01 00 06 00 00 00 02 00 0c 00 00000010: 09 00 01 00 00 00 00 00 02 00 0c 00 0a 00 01 00 00000020: 01 00 00 00 The previous 8-byte structure corrupts the parsing of subsequent TLVs, leading to unhandled delete events and erroneous session deletions. Consequently, clients that create and tear down BA sessions in batches (such as Apple Wi-Fi clients) fail to properly clean up stale sessions, causing HW_RRO to be lost upon subsequent reassociations. Fixes: a5d028d66836 ("wifi: mt76: mt7996: add wed rro delete session garbage collector") Signed-off-by: Tao Gong Link: https://patch.msgid.link/20260823053739.186748-1-gongtao0607@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3857bf5aa37cf1c1f9911a088a852e9c2e08dc83 Author: Aaron Ma Date: Wed Aug 26 12:36:58 2026 +0800 wifi: mt76: mt7925: restore the legacy BSS after MLO teardown [ Upstream commit 8f9e5807671ee97cacf1957f4a09e43f4f1017a9 ] Removing the last link of an MLD interface leaves the firmware with the MLD BSS and DEV entry: the removal loop skips the deflink, and the hweight16(mvif->valid_links) fallback reads the stale pre-update valid_links, which is still non-zero. The entry keeps the per-link MAC address, so every subsequent legacy association fails authentication until the interface is removed or the module is reloaded. Remove the deflink BSS and add it back as a legacy BSS on the transition to zero links. Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links") Signed-off-by: Aaron Ma Link: https://patch.msgid.link/20260826043658.2255553-1-aaron.ma@canonical.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5877d7138cc4359d26fd7b010eedfd1b3162348f Author: Filipe Manana Date: Fri Sep 25 13:47:21 2026 +0100 btrfs: fix xattr replace when multiple xattrs are packed in the same item [ Upstream commit 858bee1c77857aabcc2327cd32dd8266332de332 ] If we have a btrfs_dir_item item that packs multiple xattrs and then we replace the value of one of them (with the setxattr(2) family of syscalls) with another value of a different size, we end up not having a fully initialized btrfs_dir_item, resulting in a corruption that the tree checker will detect at extent buffer writeback time. This is because in btrfs_setxattr() when we find a btrfs_dir_item with multiple xattrs (due to the crc32c hash of their name being the same) we delete one of the xattr items (btrfs_dir_item) and then insert a new one, but the deletion and insertion results in shifting existing data in the leaf and therefore when the new value of a xattr has a different size, the new btrfs_dir_item is placed in a leaf section that was not initialized and we only copy the value's data and set the value's length in the new btrfs_dir_item, without setting the name, the name's length, the key (which must be all zeroes for xattrs), flags (BTRFS_FT_XATTR) and transaction ID. The following script reproduces the issue: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV mount $DEV $MNT touch $MNT/testfile # Add two xattrs that, on btrfs, have the same hash (crc32c) for their # name and therefore are packed into the same btrfs_dir_item. setfattr -n user.foobar -v 123 $MNT/testfile setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile # Verify the xattrs are present. echo "xattrs before:" getfattr --absolute-names --dump $MNT/testfile # Now replace the value of the foobar xattr with a significantly larger # value. setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile # Check the xattrs have the expected values. echo "xattrs after:" getfattr --absolute-names --dump $MNT/testfile umount $MNT Running it: $ ./test.sh (...) xattrs before: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" user.foobar="123" xattrs after: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" So the "user.foobar" xattr is missing and there was a transaction abort when unmounting the fs with the following traces in dmesg: $ dmesg [869800.159271] BTRFS warning (device sdi): access to eb bytenr 30474240 len 16384 out of range start 16015 len 25964 [869800.159293] ------------[ cut here ]------------ [869800.159296] WARNING: fs/btrfs/extent_io.c:4408 at report_eb_range+0x44/0x60 [btrfs], CPU#8: getfattr/2605179 [869800.168961] Modules linked in: btrfs dm_thin_pool (...) [869800.190527] CPU: 8 UID: 0 PID: 2605179 Comm: getfattr Tainted: G W 7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full) [869800.193726] Tainted: [W]=WARN [869800.194502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [869800.197576] RIP: 0010:report_eb_range+0x44/0x60 [btrfs] [869800.198985] Code: 48 8b 7b 18 (...) [869800.203531] RSP: 0018:ffffce4541937d58 EFLAGS: 00010246 [869800.204609] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000 [869800.206137] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc04c92a0 [869800.207645] RBP: 0000000000003e8f R08: 0000000000000000 R09: 3fffffffffefffff [869800.226175] R10: ffffce4541937a88 R11: 0000000000000003 R12: 000000000000656c [869800.227594] R13: ffff8dde14be800f R14: 000000000000656c R15: 0000000000000069 [869800.229097] FS: 00007f59023bb780(0000) GS:ffff8de5788ed000(0000) knlGS:0000000000000000 [869800.231137] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [869800.232321] CR2: 0000558dc45e6a78 CR3: 0000000765b16004 CR4: 0000000000370ef0 [869800.233783] Call Trace: [869800.234330] [869800.234791] read_extent_buffer+0x4d/0x100 [btrfs] [869800.235898] btrfs_listxattr+0x199/0x240 [btrfs] [869800.236912] vfs_listxattr+0x51/0xa0 [869800.237683] listxattr+0x7e/0x100 [869800.238398] path_listxattrat+0x9e/0x190 [869800.239117] do_syscall_64+0x89/0x470 [869800.239877] entry_SYSCALL_64_after_hwframe+0x76/0x7e [869800.240914] RIP: 0033:0x7f59024cdcb7 [869800.241686] Code: f0 ff ff 73 (...) [869800.245353] RSP: 002b:00007ffd056dcdb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000c2 [869800.246892] RAX: ffffffffffffffda RBX: 00007ffd056df2e2 RCX: 00007f59024cdcb7 [869800.248853] RDX: 0000000000006600 RSI: 0000558dc45e0470 RDI: 00007ffd056df2e2 [869800.250514] RBP: 00007ffd056df2e2 R08: 0000000000006600 R09: 0000000000006600 [869800.252295] R10: 0000000000000004 R11: 0000000000000246 R12: 00000000ffffff9c [869800.254105] R13: 0000558dc45e0470 R14: 0000000000006600 R15: 0000000000000000 [869800.255931] [869800.256529] ---[ end trace 0000000000000000 ]--- [869800.260071] page: refcount:2 mapcount:0 mapping:000000007ccfc77f index:0x1d10 pfn:0x608c69 [869800.260075] memcg:ffff8dde00344d40 [869800.260076] aops:btree_aops [btrfs] ino:1 [869800.260151] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [869800.260154] raw: 017fffc00000402a fffff4adc773d4c8 fffff4adc48f3d88 ffff8de36504ba30 [869800.260155] raw: 0000000000001d10 ffff8dde054b8738 00000002ffffffff ffff8dde00344d40 [869800.260156] page dumped because: eb page dump [869800.260157] BTRFS critical (device sdi): corrupt leaf: root=5 block=30474240 slot=5 ino=257, invalid location key type, have 46, expect 132 or 1 [869800.260161] BTRFS info (device sdi): leaf 30474240 gen 9 total ptrs 6 free space 15629 owner 5 [869800.260163] BTRFS info (device sdi): refs 3 lock_owner 0 current 2550294 [869800.260164] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [869800.260165] inode generation 3 transid 0 size 0 nbytes 16384 [869800.260166] block group 0 mode 40755 links 1 uid 0 gid 0 [869800.260167] rdev 0 sequence 0 flags 0x0 [869800.260168] atime 1790340637.0 [869800.260169] ctime 1790340637.0 [869800.260169] mtime 1790340637.0 [869800.260170] otime 1790340637.0 [869800.260170] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [869800.260172] index 0 name_len 2 [869800.260172] item 2 key (256 DIR_ITEM 982728850) itemoff 16073 itemsize 38 [869800.260173] location key (257 1 0) type 1 [869800.260174] transid 9 data_len 0 name_len 8 [869800.260175] item 3 key (257 INODE_ITEM 0) itemoff 15913 itemsize 160 [869800.260176] inode generation 9 transid 9 size 0 nbytes 0 [869800.260177] block group 0 mode 100664 links 1 uid 0 gid 0 [869800.260177] rdev 0 sequence 0 flags 0x0 [869800.260178] atime 1790340638.38778502 [869800.260179] ctime 1790340638.38778502 [869800.260179] mtime 1790340638.38778502 [869800.260180] otime 1790340638.38778502 [869800.260180] item 4 key (257 INODE_REF 256) itemoff 15895 itemsize 18 [869800.260181] index 2 name_len 8 [869800.260182] item 5 key (257 XATTR_ITEM 751495445) itemoff 15779 itemsize 116 [869800.260183] location key (0 0 0) type 8 [869800.266052] transid 9 data_len 6 name_len 13 [869800.266053] location key (8243121639454149888 46 7229457603934778967) type 0 [869800.266055] transid 113 data_len 26 name_len 0 [869800.266056] location key (8608196880778817904 120 162425) type 9 [869800.266057] transid 8391162079612502016 data_len 26982 name_len 25964 [869800.266058] BTRFS error (device sdi): block=30474240 write time tree block corruption detected [869800.266091] ------------[ cut here ]------------ [869800.266092] WARNING: fs/btrfs/disk-io.c:336 at btree_csum_one_bio+0x20b/0x220 [btrfs], CPU#7: kworker/u50:7/2550294 [869800.268392] Modules linked in: btrfs dm_thin_pool (...) [869800.365851] CPU: 7 UID: 0 PID: 2550294 Comm: kworker/u50:7 Tainted: G W 7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full) [869800.368937] Tainted: [W]=WARN [869800.369834] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [869800.372778] Workqueue: writeback wb_workfn (flush-btrfs-3821) [869800.374314] RIP: 0010:btree_csum_one_bio+0x20b/0x220 [btrfs] [869800.375915] Code: 89 44 24 04 (...) [869800.380639] RSP: 0018:ffffce4548e3f7d0 EFLAGS: 00010246 [869800.382008] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000 [869800.383850] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8de091c2ddc0 [869800.385710] RBP: ffff8dde196a2000 R08: 0000000000000000 R09: 3fffffffffefffff [869800.387388] R10: ffffce4548e3f500 R11: 0000000000000003 R12: ffffce4548e3f7d8 [869800.388973] R13: ffff8dde196a2000 R14: ffff8de36504b750 R15: ffff8dde4c497b00 [869800.390414] FS: 0000000000000000(0000) GS:ffff8de5788ad000(0000) knlGS:0000000000000000 [869800.392002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [869800.393160] CR2: 000055cd6e92ad5c CR3: 00000007cb264001 CR4: 0000000000370ef0 [869800.394595] Call Trace: [869800.395113] [869800.395570] btrfs_submit_bbio+0x872/0x890 [btrfs] [869800.397284] write_meta_extent_buffer+0x70/0x80 [btrfs] [869800.398940] btree_writepages+0x141/0x4f0 [btrfs] [869800.400426] ? get_random_u32+0x8a/0xf0 [869800.401417] ? build_slab_freelist+0x47/0x130 [869800.402574] ? preempt_count_add+0x6b/0xa0 [869800.403633] ? _raw_spin_lock_irqsave+0x23/0x50 [869800.404807] ? _raw_spin_unlock_irqrestore+0x22/0x40 [869800.406085] ? alloc_from_new_slab+0x18f/0x330 [869800.407223] do_writepages+0xc6/0x160 [869800.408191] ? refill_objects+0xd8/0x300 [869800.409211] __writeback_single_inode+0x42/0x350 [869800.410408] writeback_sb_inodes+0x231/0x560 [869800.411511] wb_writeback+0x8a/0x300 [869800.412440] wb_workfn+0xbf/0x460 [869800.413291] ? _raw_spin_unlock+0x14/0x30 [869800.414328] ? finish_task_switch.isra.0+0xb9/0x380 [869800.415105] process_one_work+0x1d1/0x3d0 [869800.416633] worker_thread+0x1c4/0x330 [869800.417467] ? __pfx_worker_thread+0x10/0x10 [869800.418452] kthread+0xfc/0x130 [869800.419257] ? __pfx_kthread+0x10/0x10 [869800.420089] ret_from_fork+0x1f7/0x2c0 [869800.420863] ? __pfx_kthread+0x10/0x10 [869800.421654] ret_from_fork_asm+0x1a/0x30 [869800.422484] [869800.422953] ---[ end trace 0000000000000000 ]--- [869800.424005] BTRFS error (device sdi state A): Transaction 9 aborted (-EIO) [869800.424010] BTRFS: error (device sdi state A) in __btrfs_run_delayed_items:1162: errno=-5 IO failure [869800.424011] BTRFS info (device sdi state EA): forced readonly [869800.424013] BTRFS warning (device sdi state EA): Skipping commit of aborted transaction. [869800.424014] BTRFS: error (device sdi state EA) in cleanup_transaction:2076: errno=-5 IO failure Fix this by always setting all fields in the new btrfs_dir_item when we replace an existing xattr. Fixes: 5f5bc6b1e2d5 ("Btrfs: make xattr replace operations atomic") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9e6e496fd9271307078fd9f36d2a71d500856e78 Author: Fuad Tabba Date: Wed Sep 30 13:12:12 2026 +0100 arm64/boot: Don't set PMUv3p9 FGT2 bits without PMUv3 [ Upstream commit b52ef450139f5632d7e53e6fd5f5ec46c7029dac ] On a CPU with FGT2 and an IMPLEMENTATION DEFINED PMU (PMUVer 0b1111), __init_el2_fgt2 sets the PMUv3p9 bits in HDFGRTR2_EL2 and HDFGWTR2_EL2, which are RES0 there. The macro only checks that PMUVer is at least PMUv3p9, and 0b1111 passes. Exclude 0b1111 before the compare, as __init_el2_debug does. Fixes: 858c7bfcb35e1 ("arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9") Signed-off-by: Fuad Tabba Reviewed-by: Bradley Morgan Reviewed-by: Anshuman Khandual Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 32f21607911a1f69c8f0f93a6c28fe6f8490aa98 Author: Sang-Hoon Choi Date: Wed Sep 30 16:08:58 2026 +0900 nvmet: use the local P2P device on metadata allocation failure [ Upstream commit 4aa9c0f377a4de5e8fddce76b34ee4529639a1ff ] nvmet_req_alloc_p2pmem_sgls() assigns req->p2p_dev only after the data and metadata SGL allocations succeed. If the data allocation succeeds but the metadata allocation fails, out_free_sg passes req->p2p_dev to pci_p2pmem_free_sgl() before that assignment has taken place. Pass the local p2p_dev argument instead, so cleanup uses the same PCI device as the successful data allocation. Fixes: bcd9a0797d73 ("nvmet: fix freeing unallocated p2pmem") Reported-by: Changyul Lee Reviewed-by: Maurizio Lombardi Signed-off-by: Sang-Hoon Choi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 78859c5dbff011801cf8d5915fddc80178b4165d Author: Mahantesh Salimath Date: Thu Sep 10 16:11:24 2026 +0000 tee: optee: ffa: support shared memory offsets on large-page kernels [ Upstream commit 3c0d2f1f431c51a11253f28763be723ac782fd7a ] OP-TEE FF-A memory objects use 4 KiB pages, while the kernel page size may be larger. Consequently, tee_shm->offset can be greater than or equal to FFA_PAGE_SIZE, but OP-TEE rejects such a value in internal_offs. Do not encode the excess page offset in offs_low/offs_high. Those fields describe the logical memref offset and are copied back into tee_param->shm_offs on return. Folding the page offset into them breaks parameter round trips when a memref is reused. They are also ignored by the OPTEE_RPC_CMD_SHM_ALLOC response path, which uses only global_id and internal_offs to construct the shared-memory mobj. Instead, start the FF-A descriptor at the 4 KiB page containing the shared buffer, the same approach as optee_fill_pages_list() in the SMC ABI. Store the remaining in-page offset in internal_offs and preserve shm_offs in offs_low/offs_high. This keeps internal_offs within the FF-A page size, maps RPC allocations at the correct address, and preserves normal memref offsets across repeated invocations. Tested on ARMv8-A with 64 KiB PAGE_SIZE. OP-TEE OS ran as a secure partition under Hafnium (SPMC) over FF-A. Verified registered shared memory with tee_shm->offset >= 4 KiB, memref reuse on the same TEEC_Operation, and RPC OPTEE_RPC_CMD_SHM_ALLOC (xtest regression 6007-6009). optee_hello_world, optee_aes, and xtest regression 1005, 1007, 1008, 4001-4003 and 6001-6003 also passed. Fixes: 4615e5a34b95 ("optee: add FF-A support") Acked-by: Liming Sun Acked-by: James Hurley Acked-by: Dave Thompson Signed-off-by: Mahantesh Salimath Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 9f7ee4d73aaecd86981a71eeea8eacf192a51989 Author: Rodrigo Zaiden Date: Sun Mar 22 13:31:14 2026 -0300 tee: optee: fix kernel-doc warnings [ Upstream commit 3faa6774ffc5973af39ac9c4f1fe93aa92ec9407 ] Fix kernel-doc issues in optee_private.h and optee_msg.h: - Add missing documentation for struct members: optee_msg_param_value, optee_msg_param, optee_msg_arg, optee, and optee_ffa; - Ensure member descriptions follow the order of declaration; - Use consistent formatting (lowercase descriptions and ':' after member names); - Adjust indentation for better alignment; This resolves kernel-doc warnings such as missing member descriptions and incorrect prototype documentation. No functional changes. Signed-off-by: Rodrigo Zaiden Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Stable-dep-of: 3c0d2f1f431c ("tee: optee: ffa: support shared memory offsets on large-page kernels") Signed-off-by: Sasha Levin commit 0fb48179f7a1a89f61ece10b50d3aa6fa1a27ce9 Author: Jens Wiklander Date: Wed Aug 13 08:02:50 2025 +0200 optee: sync secure world ABI headers [ Upstream commit 15003d9cc65fe7d4cbc9b25d6dccfc3e58d4d483 ] Update the header files describing the secure world ABI, both with and without FF-A. The ABI is extended to deal with protected memory, but as usual backward compatible. Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Stable-dep-of: 3c0d2f1f431c ("tee: optee: ffa: support shared memory offsets on large-page kernels") Signed-off-by: Sasha Levin commit bcf97573d44e277b1744d7f1226f665aa0ccc599 Author: Sang-Hoon Choi Date: Wed Sep 30 02:37:34 2026 +0900 cxgb4/ch_ktls: disable softirqs around tid_list erases [ Upstream commit 4c9dc0faca98084922caeb689579d338cf3e1c29 ] chcr_ktls_cpl_act_open_rpl() inserts into tid_list from the receive path using xa_insert_bh(). The array is shared by the adapter's connections and initialized with XA_FLAGS_LOCK_BH. However, chcr_ktls_dev_del() and the chcr_ktls_dev_add() error path use xa_erase(), which takes the XArray lock without disabling softirqs. When cleanup runs with softirqs enabled, a receive softirq for another connection on the same CPU can interrupt the erase and spin on the lock held by the interrupted task. Use xa_erase_bh() at both sites to match the insertion path. Fixes: 65e302a9bd57 ("cxgb4/ch_ktls: Clear resources when pf4 device is removed") Reported-by: Changyul Lee Assisted-by: LLM Signed-off-by: Sang-Hoon Choi Reviewed-by: Ayush Sawal Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e7183b7d518ce8b3e1f7284f9881d7a87569df14 Author: Omar Ramadan Date: Mon Sep 28 23:23:11 2026 +0300 amt: send the relay's General Query directly from the receive path [ Upstream commit afae89de73dd693cfa329580ba0fba63bd3f0a11 ] An skb queued in a qdisc can outlive the tunnel it references through a raw pointer in skb->cb. For example, with igmp_qrv set to 1 on the relay a tunnel lives for 135s, so a netem delay of 180s on the amt device outlives it; when the tunnel expires and is freed, the subsequent dequeue triggers a use-after-free in amt_dev_xmit(). BUG: KASAN: slab-use-after-free in amt_dev_xmit+0x2763/0x2e20 Call Trace: amt_dev_xmit+0x2763/0x2e20 [drivers/net/amt.c:1262] dev_hard_start_xmit+0x22f/0x620 sch_direct_xmit+0x12e/0xac0 netem_dequeue+0x333/0xc50 net_tx_action+0x35c/0xa60 amt_send_igmp_gq() and amt_send_mld_gq() are only called from amt_request_handler(), inside the rcu_read_lock_bh() section of amt_rcv(). amt_request_handler() already has the tunnel the query is for: it found or created it inside that section. Queuing the query with dev_queue_xmit() only leads back into amt_dev_xmit(), which strips the Ethernet header and calls amt_send_membership_query() for that tunnel. Make that call directly from the two senders instead, the same way amt_send_advertisement() transmits from the receive path. The query never waits in a qdisc, the tunnel is only dereferenced inside the RCU section that found or created it, and nothing is stored in skb->cb, so no lookup or refcount is needed. Remove the query branch of amt_dev_xmit(), amt_skb_cb() and struct amt_skb_cb, which have no users left. Behaviour changes: - The relay's own General Queries no longer pass through the amt device's egress path: its qdisc, tc egress (clsact/tcx), the netfilter egress hook and packet taps. They are still visible as UDP on the underlay. - A query that is sent successfully is no longer counted as tx_dropped. The old query branch left through the unlock label, which counted every sent query as dropped. - A query that reaches amt_dev_xmit() on a relay from elsewhere, such as a userspace querier, is now dropped at the IGMP/MLD type switch. Before, it trusted whatever skb->cb held, and a NULL tunnel hit the WARN_ON(1). Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft Security FORGE Labs) Signed-off-by: Omar Ramadan Link: https://patch.msgid.link/20260928202312.74574-2-omar@blockcast.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 22182f91c6703af6e9832cffe6d22b381031cb5a Author: Jamal Hadi Salim Date: Wed Sep 30 03:31:02 2026 -0400 net/sched: em_text: reject unterminated algo before autoload [ Upstream commit c9728fcf2e7fb4a7a8d08ebd9524c3b02ae1a021 ] This is a follow-up to commit 9c572a83037a ("net/sched: fix potential stack infoleak in em_text_dump()"), which zero-initialised the dump-side struct. Sashiko pointed at a pre-existing bug that exposed the change-side input-validation gap open. em_text_change() casts the raw netlink attribute payload to struct tcf_em_text and passes conf->algo, a 16-byte array with no enforced NUL terminator, to textsearch_prepare(). On the TS_AUTOLOAD retry textsearch_prepare() calls request_module("ts_%s", algo); vsnprintf() walks %s until it finds a NUL, so an algo[] with no NUL reads past the array into the adjacent struct fields and payload and feeds those bytes to the usermode helper command line. This is an out-of-bounds read and a kernel memory disclosure. Reject the attribute when no NUL exists within TC_EM_TEXT_ALGOSIZ bytes, matching the check xt_string has had since 3ab720881b6e. Conditions to recreate the bug: - CAP_NET_ADMIN on the target netns (namespace-local via unshare -Urn is enough) - install clsact on an interface, then add a basic filter with one text ematch whose algo[] is 16 bytes with no NUL (e.g. "A"*16) and pattern_len at least 1 - the add fails with -ENOENT and the kernel invokes modprobe with a module name made of "ts_" plus the 16 bytes and the adjacent payload Fixes: d675c989ed2d4 ("[PKT_SCHED]: Packet classification based on textsearch (ematch)") Reported-by: Sashiko (gemini) Closes: https://sashiko.dev/#/patchset/20260918133953.12494-1-bernard.ladenthin%40gmail.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2DIU.v1.20260929183844@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 035ad1bc964f6698e9b06c26ffe94bcac08dadea Author: Maíra Canal Date: Wed Sep 30 16:06:50 2026 -0300 drm/vc4: Free the BO cache size list on teardown [ Upstream commit b41ff8b529278216cba22a5dcdc93fea2a3a9619 ] vc4_bo_cache_destroy() purges the cached BOs but never frees the size list, leaking it on every unbind. Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Assisted-by: LLM Reviewed-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20260930190721.1897264-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit bacc07fa343f42e37896160244248056b3e65917 Author: Myeonghun Pak Date: Sun Sep 13 18:30:19 2026 -0400 drm/aspeed: Balance the display clock enable on teardown [ Upstream commit ecce445c6489895463b7ddec2af66338287fee4c ] aspeed_gfx_load() enables the display clock without checking the return value and never disables it on probe failure or removal. devm_clk_get() only releases the clock reference, leaving the enable unbalanced. Use devm_clk_get_enabled() to handle enable failures and automatically disable and unprepare the clock on probe failure or removal. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 4f2a8f5898ec ("drm: Add ASPEED GFX driver") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260913223019.89651-1-mhun512@gmail.com Link: https://patch.msgid.link/20260905080426.34224-1-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit b78c114600ae3df90c083c72c290437b068577c8 Author: Sang-Hoon Choi Date: Wed Sep 30 02:37:31 2026 +0900 gpio: exar: initialize the ID before registering its cleanup [ Upstream commit 4d69e74034b208588636ecc177e0dd43a7696af3 ] devm_add_action_or_reset() invokes the cleanup action immediately when registering the action fails. gpio_exar_probe() currently stores the allocated ID in exar_gpio only after registering the action, so that failure makes exar_devm_ida_free() release ID 0. If the allocated ID is nonzero, this leaks that ID and can free ID 0 belonging to another device. Store the ID before registering the cleanup action so both the immediate failure path and normal device teardown release the correct allocation. Fixes: 5300ebb695fa ("gpio: exar: use devm action for freeing the IDA and drop remove()") Reported-by: Changyul Lee Assisted-by: LLM Signed-off-by: Sang-Hoon Choi Reviewed-by: Linus Walleij Link: https://patch.msgid.link/179070265834.12871.48183786512201899.idr-bug-79@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 21c1fcd784c24c427b5207d8b6906b25d2857274 Author: Oleg Keri Date: Fri Sep 25 15:25:58 2026 +0200 drm/dp: don't mark the AUX backlight enabled when enabling failed [ Upstream commit 707ce102521496c67860d81221b20c56d8255f2f ] If drm_edp_backlight_enable() fails, dp_aux_backlight_update_status() still marks the backlight as enabled. From then on every brightness change only updates the level and the enable is never retried, so the panel stays dark until something blanks and unblanks the backlight. Return the error instead, so the next update tries to enable again. Fixes: 10f7b40e4f30 ("drm/panel: add basic DP AUX backlight support") Signed-off-by: Oleg Keri Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260925132558.27518-1-okerixx@gmail.com Signed-off-by: Sasha Levin commit b854669a57a20f2db3b3d831b73eb7c0ef37ea94 Author: Sai Teja Aluvala Date: Tue Sep 29 11:42:33 2026 +0530 Bluetooth: btintel_pcie: Add shared HW reset for clean start [ Upstream commit 1465494e8d07426fa41c0021530cccb2a1ac38fa ] Reset shared Bluetooth hardware after mapping the BAR and before setting up MSI-X interrupts, so stale device state is cleared before IRQ handlers and interrupt masks are configured. Propagate reset errors so probe aborts rather than continuing when the reset fails. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e83953022836014f6d7ea7c698c2571c14ba0b68 Author: Kiran K Date: Tue Oct 1 16:14:51 2024 +0530 Bluetooth: btintel_pcie: Add recovery mechanism [ Upstream commit a430c2a10c743dab5a3a07bc4e9544c55bd010fd ] This patch adds a recovery mechanism to recover controller if firmware download fails due to unresponsive controller, command timeout, firmware signature verification failure etc. Driver attmepts maximum of 5 times before giving up. Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 1465494e8d07 ("Bluetooth: btintel_pcie: Add shared HW reset for clean start") Signed-off-by: Sasha Levin commit 08704ec6d4bf69725e7815b09a9b5c7af83e255b Author: Ravindra Date: Tue Sep 29 12:26:41 2026 +0530 Bluetooth: btintel_pcie: fix TX descriptor bounds check [ Upstream commit baa53af641c9e3644e717b8dfd1b95a55a0c111b ] btintel_pcie_prepare_tx() uses tfd_index to access the TFD and data buffer arrays before the index is advanced modulo txq->count. An index equal to txq->count is one past the end of both arrays, so reject it in the bounds check. Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware") Signed-off-by: Ravindra Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 86b8bbc54cbf5e27796f464ffc8a79fa15420212 Author: Vincent Jardin Date: Mon Aug 24 23:25:31 2026 +0200 arm64: dts: lx2160a: fix the iic5 spi3 pinmux offset and value [ Upstream commit f14f4dc8ea3810f8ed4f0f3ea13f8bba3e2b0f04 ] The iic5-spi3-pins node has both of its first two cells wrong. The offset selects the register within the node's reg range, where: 0x0 is RCWSR12, 0x4 is RCWSR13, 0x8 is RCWSR14. An offset of 0x3 is not one of them and is not even aligned for the declared 32 bit register width. It is the only node in this pinmux that does not use 0x0, 0x4 neither 0x8. The value is wrong too: IIC5_PMUX is RCWSR12[11:9] and it encodes 0b000 for IIC5, 0b001 for GPIO_1[25:24], 0b010 for SDHC1_CLK_SYNC_OUT/IN, 0b011 for {IIC5_SCL,IIC5_SDA} = {SPI3_SOUT,SPI3_SIN}. This node selects the last of those, so it needs 0x3, not the 0x2, which is the value of the neighbouring sdhc1 clock sync node it was copied from. Fixes: 284ad7064aaa ("arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word") Reviewed-by: Josua Mayer Signed-off-by: Vincent Jardin Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit b96149228ca143cc9dd3beff3e2f4a37b332314b Author: Vincent Jardin Date: Mon Aug 24 23:25:30 2026 +0200 arm64: dts: lx2160a: fix IIC1 pinmux submask rejected by pinctrl-single [ Upstream commit 6affdda171ca8f2e082e8c4fba56233a2f8c9910 ] IIC1_PMUX is a single bit field at RCWSR14 bit 10, so the mask for the two iic1 pinmux nodes was narrowed from 0x7 to 0x1 to avoid writing the two reserved bits next to it. With pinctrl-single,bit-per-mux the driver does not take the supplied mask as the bits to modify. It derives the field from the node's pinctrl-single,function-mask, which is 0x7 here, and then requires the supplied mask to match it exactly: bit_pos = __ffs(mask); /* 10 */ mask_pos = ((pcs->fmask) << bit_pos); /* 0x7 << 10 = 0x1c00 */ submask = mask & mask_pos; /* 0x400 */ ... if (submask != mask_pos) { dev_warn(pcs->dev, "Invalid submask 0x%x for %pOFn at 0x%x\n", submask, np, offset); continue; } A one bit mask gives submask 0x400 against mask_pos 0x1c00, so both nodes are rejected and the pins are never muxed with this message: pinctrl-single 70010012c.pinmux: Invalid submask 0x400 for iic1-i2c-pins pinctrl-single 70010012c.pinmux: Invalid submask 0x400 for iic1-gpio-pins The values are not changed: - 0x0 selects IIC1 - 0x1 << 10 selects GPIO_1[3:2]. Fixes: 7a3cc49ad1fc ("arm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bit") Signed-off-by: Vincent Jardin Reviewed-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 9a384b912eb4be6e45e146b4436897fc71033d97 Author: Vincent Jardin Date: Mon Aug 24 23:25:29 2026 +0200 arm64: dts: lx2160a: fix incorrect pinmux [ Upstream commit 8188a59dd6782786556b18f515090b79cb701c45 ] For gpio1 value set for pinctrl is outside the mask and so will do nothing. Add the missing offset for value field to be the same as the mask as expected. Fixes: 284ad7064aaa ("arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word") Suggested-by: Thibaut Collet Reviewed-by: Josua Mayer Signed-off-by: Vincent Jardin Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 35f2013f83ef16f9f0331c4c3a8e8d161580d574 Author: Christian Brauner Date: Fri Oct 2 15:52:36 2026 +0200 namespace: refuse an automount below a mount that is in no namespace commit ba985ce08471c555af2a2fbe217c1bc2e72a6d8c upstream. It's possible to add autmounts even when the parent mount isn't in the mount namespace of the caller. The only requirement we have is that the parent mount namespace must not be NULL, i.e., unmounted. Problem is that clone_private_mount() has MNT_NS_INTERNAL which makes that trivially true. So that passes the test and attach_recursive_mnt() accepts that as a mount point and funny enough, count_mounts() dereferences MNT_NS_INTERNAL. The problem is it is an error pointer... So we can reach this in userspace via fanotify. A filesystem mark on the lower filesystem of an overlay reports paths on the layer clone and reading the event hands out a descriptor on it. For example with debugfs as the lower layer it goes kaboom: openat(evfd, "tracing", O_DIRECTORY) Oops: general protection fault KASAN: null-ptr-deref in range [0x1d0-0x1d7] RIP: 0010:count_mounts+0x35/0x200 attach_recursive_mnt finish_automount And since that sleeping beauty happens under namespace_sem held for writing every mount operation on the system blocks from then on. Congrats. Use is_mounted() instead which rejects unmounted and internal mounts alike. The open fails with EINVAL just as it did before clone_private_mount() used MNT_NS_INTERNAL. Fixes: df820f8de4e4 ("ovl: make private mounts longterm") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-5-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e2b10181d913b4efa3a8dc67a532f859aa5f95e0 Author: Christian Brauner Date: Fri Oct 2 15:52:33 2026 +0200 namei: don't reveal overmounted entries in refwalk commit 8189ab688f5a2c745dc90b63374da02f213d6994 upstream. In rcuwalk the dentry is validated before it is accepted. step_into() step_into() rechecks d_seq and __follow_mount_rcu() rechecks mount_lock. An entry that gets unlinked in between causes the lookup to retry and miss. A refwalk doesn't do this. lookup_fast() takes a reference on the hashed dentry and simply accepts it. So an unlink that happens after the reference was taken isn't seen by refwalk. That's fine for a simple file. We just happened to open it before it was unlinked, no problem. For a mountpoint and specifically a locked mountpoint it very much isn't. The unlink detaches all mounts and then removes the name. Any refwalk that hasn't traversed the mounts yet simply reveals the underlying entry. It's a very narrow window but it can be hit: reads of a covered file in 60 s, 3 walkers, ~15000 unlinks no widening 27 that step + 200 us 3741 See the appended patch for a more reliable reproducer. So check the entry after step_into(). unlink(), rmdir() and rename() mark the dentry with dont_mount() before they detach the mounts and remove the dentry. So a dentry that is marked with DCACHE_CANT_MOUNT and is unhashed by the time its mounts were looked at is a name that was unlinked under the refwalk. DCACHE_CANT_MOUNT is read after the mounts were looked up and it is set before they are detached by detach_mounts(). A refwalk that missed the mounts will see DCACHE_CANT_MOUNT. Plain d_unlinked() is fine. A rename takes the dentry off its hash chain but ___d_drop() leaves d_hash.pprev set. So only __d_drop() and a rename over the dentry unhash it. The only move that flips IS_ROOT splices in a disconnected alias. That doesn't have DCACHE_CANT_MOUNT set. Add the to step_into_slowpath(). ".." and LOOKUP_DOWN may legitimately land on an unhashed directory. A refwalk that crossed onto a mount has path.mnt different from nd->path.mnt. A dentry that a filesystem dropped on its own (d_invalidate(), d_drop()) doesn't have the flag set and is treated as before. // SPDX-License-Identifier: GPL-2.0 /* * unlink_covered: unlink a file that is a mountpoint in a detached copy of * its mount, against walkers that open it through that copy. * * A is a tmpfs with the file f1 (content SECRET_F) and the plain file * MARK_A. A' is an open_tree(OPEN_TREE_CLONE) copy of A with MARK_A bound * on A'/f1, held through an O_PATH fd on its root once the tree fd is * closed. Walkers open f1 through that fd while the driver unlinks A/f1, * where nothing is mounted on it. A walker may read MARK_A or get ENOENT. * A read of SECRET_F is a hit: the name was found after its mount was * gone. The lockless walks use openat2(RESOLVE_CACHED). * * usage: unlink_covered [-t seconds] [-w walkers] */ #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include #include #include #include #include #include #include #include #include #include #include #include #ifndef __NR_open_tree #define __NR_open_tree 428 #endif #ifndef __NR_move_mount #define __NR_move_mount 429 #endif #ifndef __NR_openat2 #define __NR_openat2 437 #endif #ifndef OPEN_TREE_CLONE #define OPEN_TREE_CLONE 1 #endif #ifndef OPEN_TREE_CLOEXEC #define OPEN_TREE_CLOEXEC O_CLOEXEC #endif #ifndef MOVE_MOUNT_F_EMPTY_PATH #define MOVE_MOUNT_F_EMPTY_PATH 0x00000004 #endif #define WORK "/tmp/uc" #define ADIR WORK "/A" static int duration = 60, nwalkers = 3; static atomic_int stop, writer_waiting; static pthread_rwlock_t cur_lock = PTHREAD_RWLOCK_INITIALIZER; static int cur_fd = -1; /* the root of A', -1 while there is none */ static atomic_long n_unlink, n_walk, n_mark, n_enoent, n_other, n_secret, n_secret_cached; static void die(const char *what) { fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno)); exit(2); } static void put_file(int dfd, const char *name, const char *content) { int fd = openat(dfd, name, O_CREAT | O_WRONLY | O_TRUNC | O_CLOEXEC, 0644); if (fd < 0 || write(fd, content, strlen(content)) < 0) die(name); close(fd); } /* "plain/../" @n times, then f1: a longer walk that checks nothing on its way */ static char *longpath(int n) { char *p = malloc(n * 9 + 3), *q = p; for (int i = 0; i < n; i++, q += 9) memcpy(q, "plain/../", 9); strcpy(q, "f1"); return p; } static void try_read(int dfd, const char *path, int cached) { struct open_how how = { .flags = O_RDONLY | O_CLOEXEC, .resolve = RESOLVE_CACHED }; char buf[32] = ""; long n; int fd; if (cached) fd = syscall(__NR_openat2, dfd, path, &how, sizeof(how)); else fd = openat(dfd, path, O_RDONLY | O_CLOEXEC); atomic_fetch_add(&n_walk, 1); if (fd < 0) { if (errno == ENOENT) atomic_fetch_add(&n_enoent, 1); else if (!cached || errno != EAGAIN) atomic_fetch_add(&n_other, 1); return; } n = read(fd, buf, sizeof(buf) - 1); close(fd); if (n >= 6 && !strncmp(buf, "SECRET", 6)) { if (cached) atomic_fetch_add(&n_secret_cached, 1); if (!atomic_fetch_add(&n_secret, 1)) printf("HIT: read \"%s\" through %s (%s walk)\n", buf, path, cached ? "lockless" : "any"); } else { atomic_fetch_add(&n_mark, 1); } } static void *walker(void *arg) { unsigned int r = (long)arg * 2654435761u; while (!atomic_load(&stop)) { char *p_long, *p_short; int dfd; while (atomic_load(&writer_waiting) && !atomic_load(&stop)) usleep(20); pthread_rwlock_rdlock(&cur_lock); dfd = cur_fd; if (dfd < 0) { pthread_rwlock_unlock(&cur_lock); usleep(100); continue; } r = r * 1103515245u + 12345u; p_long = longpath(1 + (r >> 8) % 400); p_short = longpath(0); try_read(dfd, p_long, 0); try_read(dfd, p_short, 0); try_read(dfd, p_long, 1); pthread_rwlock_unlock(&cur_lock); free(p_long); free(p_short); } return NULL; } /* hand the walkers a new A' (or none), close the old one */ static void publish(int fd) { int old; atomic_fetch_add(&writer_waiting, 1); pthread_rwlock_wrlock(&cur_lock); old = cur_fd; cur_fd = fd; pthread_rwlock_unlock(&cur_lock); atomic_fetch_sub(&writer_waiting, 1); if (old >= 0) close(old); } static void *driver(void *arg __attribute__((unused))) { int a; if (mkdir(ADIR, 0755) && errno != EEXIST) die("mkdir A"); if (mount("A", ADIR, "tmpfs", 0, "size=4M")) die("mount A"); a = open(ADIR, O_PATH | O_DIRECTORY | O_CLOEXEC); if (a < 0 || mkdirat(a, "plain", 0755)) die("A/plain"); put_file(a, "MARK_A", "MARK_A"); while (!atomic_load(&stop)) { int t, m, fd_a; put_file(a, "f1", "SECRET_F"); t = syscall(__NR_open_tree, a, "", OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC | AT_EMPTY_PATH); if (t < 0) die("open_tree A"); m = syscall(__NR_open_tree, a, "MARK_A", OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC); if (m < 0) die("open_tree MARK_A"); if (syscall(__NR_move_mount, m, "", t, "f1", MOVE_MOUNT_F_EMPTY_PATH)) die("move_mount"); close(m); fd_a = openat(t, ".", O_PATH | O_DIRECTORY | O_CLOEXEC); if (fd_a < 0) die("open A'"); publish(fd_a); usleep(200 + rand() % 1000); close(t); /* A' is unmounted, fd_a holds it */ usleep(200 + rand() % 1000); if (unlinkat(a, "f1", 0)) /* through A, a plain file there */ die("unlink f1"); atomic_fetch_add(&n_unlink, 1); usleep(rand() % 300); publish(-1); } close(a); umount2(ADIR, MNT_DETACH); return NULL; } int main(int argc, char **argv) { pthread_t d, *w; int c, i; setvbuf(stdout, NULL, _IOLBF, 0); while ((c = getopt(argc, argv, "t:w:")) != -1) { switch (c) { case 't': duration = atoi(optarg); break; case 'w': nwalkers = atoi(optarg); break; default: fprintf(stderr, "usage: unlink_covered [-t seconds] [-w walkers]\n"); return 2; } } if (unshare(CLONE_NEWNS) || mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL)) die("unshare"); if (mkdir(WORK, 0755) && errno != EEXIST) die("mkdir"); w = calloc(nwalkers, sizeof(*w)); for (i = 0; i < nwalkers; i++) if (pthread_create(&w[i], NULL, walker, (void *)(long)i)) die("pthread_create"); if (pthread_create(&d, NULL, driver, NULL)) die("pthread_create"); sleep(duration); atomic_store(&stop, 1); pthread_join(d, NULL); for (i = 0; i < nwalkers; i++) pthread_join(w[i], NULL); printf("unlink_covered: %d s, %d walkers: unlinks %ld walks %ld mark %ld enoent %ld other %ld SECRET %ld (lockless %ld)\n", duration, nwalkers, atomic_load(&n_unlink), atomic_load(&n_walk), atomic_load(&n_mark), atomic_load(&n_enoent), atomic_load(&n_other), atomic_load(&n_secret), atomic_load(&n_secret_cached)); return atomic_load(&n_secret) ? 1 : 0; } # diff --git a/fs/namei.c b/fs/namei.c # --- a/fs/namei.c # +++ b/fs/namei.c # @@ -35,6 +35,7 @@ # #include # #include # #include # +#include # #include # #include # #include # @@ -1205,9 +1206,26 @@ static int sysctl_protected_symlinks __read_mostly; # static int sysctl_protected_hardlinks __read_mostly; # static int sysctl_protected_fifos __read_mostly; # static int sysctl_protected_regular __read_mostly; # +/* debug: widen the two windows of the detach_mounts() race */ # +static int sysctl_detach_race_walk_us __read_mostly; # +static int sysctl_detach_race_unlink_us __read_mostly; # # #ifdef CONFIG_SYSCTL # static const struct ctl_table namei_sysctls[] = { # + { # + .procname = "detach_race_walk_us", # + .data = &sysctl_detach_race_walk_us, # + .maxlen = sizeof(int), # + .mode = 0644, # + .proc_handler = proc_dointvec, # + }, # + { # + .procname = "detach_race_unlink_us", # + .data = &sysctl_detach_race_unlink_us, # + .maxlen = sizeof(int), # + .mode = 0644, # + .proc_handler = proc_dointvec, # + }, # { # .procname = "protected_symlinks", # .data = &sysctl_protected_symlinks, # @@ -1878,6 +1896,10 @@ static struct dentry *lookup_fast(struct nameidata *nd) # dentry = __d_lookup(parent, &nd->last); # if (unlikely(!dentry)) # return NULL; # + /* debug: between finding a mountpoint and crossing its mounts */ # + if (unlikely(sysctl_detach_race_walk_us) && d_mountpoint(dentry)) # + usleep_range(sysctl_detach_race_walk_us, # + sysctl_detach_race_walk_us + 10); # status = d_revalidate(nd->inode, &nd->last, dentry, nd->flags); # } # if (unlikely(status <= 0)) { # @@ -5693,6 +5715,10 @@ int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir, # if (!error) { # dont_mount(dentry); # detach_mounts(dentry); # + /* debug: the mounts are gone, d_delete() is still to come */ # + if (unlikely(sysctl_detach_race_unlink_us)) # + usleep_range(sysctl_detach_race_unlink_us, # + sysctl_detach_race_unlink_us + 10); # } # } # } Fixes: 8ed936b5671b ("vfs: Lazily remove mounts on unlinked files and directories.") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-2-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit a256e31e0c54c4c37d2523aa52faabdcdd2ebc07 Author: Christian Brauner Date: Wed Sep 30 15:32:09 2026 +0200 namespace: don't let a pseudo dentry become the root of a mount commit b138e16fb1e81376cea89f727dda7bfccd140de4 upstream. d_alloc_pseudo() hands out dentries for pipes, sockets and other files that are never anyone's child or parent. They carry DCACHE_NORCU and dentry_free() frees them right away because no lockless path walk can ever reach them. That holds as long as such a dentry isn't the root of a mount. But bind mounting /proc/self/fd/ of such a file does exactly that. Most callers of alloc_file_pseudo() put their files on kernel-internal mounts and may_copy_tree() refuses those. bpf_token_create() doesn't. It places the token file on the bpffs mount the caller handed it and that mount is in the caller's mount namespace so the clone goes through: mount --bind /proc/self/fd/ open_tree(tokfd, "", AT_EMPTY_PATH | OPEN_TREE_CLONE) + move_mount() __follow_mount_rcu() then loads ->mnt_root of that mount, reads d_seq and d_flags of the dentry and only then checks mount_lock. The dentry can be gone by then. The final mntput() of an unmounted parent unhooks a child that stayed attached to it under mount_lock alone. When the child's holder does the final put right after that the root is dput() and freed immediately while a walker that found the mount hashed still looks at it. Refuse to clone a mount with a DCACHE_NORCU dentry as its root. Nothing sensible can be done with a bind mount of a bpf token anyway. Fixes: 35f96de04127 ("bpf: Introduce BPF token object") Cc: stable@vger.kernel.org # v6.9+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-17-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 793cb67b0f52d00c67bd0e76bc57455b5c70ebb8 Author: Christian Brauner Date: Wed Sep 30 15:32:07 2026 +0200 dcache: don't put a mountpoint on a dentry that's being removed commit 75f4197f1e11d2eb75c2d6f916a7d4764db621e5 upstream. rmdir(), unlink() and rename() call dont_mount() on the victim and then detach_mounts() with the victim's inode locked. do_lock_mount() takes the inode lock of the mountpoint and checks cant_mount() so a mount can't show up after detach_mounts(). But attach_recursive_mnt() makes a second mountpoint for the root of the source mount so that the mounts already located at the destination can be put on top of it. No inode is locked for that one and d_set_mounted() only refuses a dentry that is unlinked. Between detach_mounts() and d_delete() the victim is still hashed: rmrace: b passed dont_mount() and detach_mounts(), sleeping T2: move_mount(S, /tmp/plcant/x, BENEATH) = 0 errno 0 () T1: rmdir(/tmp/plcant/d/b) = 0 errno 0 109 107 0:61 /d/b//deleted /tmp/plcant/x rw,relatime - tmpfs tmpfs rw 108 109 0:63 / /tmp/plcant/x rw,relatime - tmpfs T rw A bind mount of the directory that's being removed is moved beneath an existing mount while the rmdir() is located between the two calls. The mount ends up on the removed directory and nothing will ever detach it. Check cant_mount() in d_set_mounted() as well. dont_mount() raises the flag under d_lock before detach_mounts() runs so either the mountpoint is set first and detach_mounts() finds the mount or the flag is seen and the mount is refused. Fixes: 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-15-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 6e4012e571867868b545c91ca9d6095fdb709907 Author: Christian Brauner Date: Wed Sep 30 15:31:54 2026 +0200 namespace: check a submount for references right before unmounting it commit 32bf92416614a1e3ff3524fc6b780259c7aad3ef upstream. shrink_submounts() and mark_mounts_for_expiry() first collect all the mounts they are allowed to unmount and then unmount them. Whether a mount is busy is decided by propagate_mount_busy() on the tree. But unmounting the first mount changes the tree that the second one propagates into. propagate_umount() moves a surviving overmount off a copy it unmounts and mounts it where the copy was mounted. If that's where the propagated copy of the second victim is looked up the overmount becomes a candidate of the second umount_tree(). It's childless and so trim_one() commits it without looking at its reference count. So a synchronous umount pulls out a busy mount that is in use somewhere else and marks it MNT_SYNC_UMOUNT while it has users: umount2(/tmp/plshrink/p1, 0) = 0 errno 0 cwd is (unreachable) The same two umounts requested one after the other fail with EBUSY. This needs a mount with MNT_SHRINKABLE, i.e., automounted submounts of NFS, AFS and CIFS or the tracefs mount below debugfs. Bind mounts inherit the flag. Check each mount right before it is unmounted under the same hold of namespace_sem and mount_lock as the umount itself. Make sure that the algorithm stays linear. Fixes: 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-2-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e92a8abef199e5314d5426da0f57f6273f0038f2 Author: Christian Brauner Date: Sat Sep 26 15:44:29 2026 +0200 fs: refuse fspick() on internal superblocks commit 02587a4af82adccaef8e3b3624b4e7f1c401632d upstream. There's a few instances where a internal superblock is reachable by fspick(). Block that. graft_tree() and fsmount() already refuse them. fanotify refuses mount and superblock marks on them for the same reason. Fixes: cf3cba4a429b ("vfs: syscall: Add fspick() to select a superblock for reconfiguration") Cc: stable@vger.kernel.org # v5.2+ Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-6-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 7e037b1fd339d865737c8accd29abcf40130a5a0 Author: Christian Brauner Date: Sat Sep 26 15:44:27 2026 +0200 namespace: don't copy an unmounted mount tree commit 8bacbf6be959973b28b691713a872c12eae69eec upstream. may_copy_tree() accepts a mount whose root is an nsfs or pidfs file before it checks whether that mount is mounted. This exception exists for nsfs and pidfs mounts. They are part of no mount namespace so neither check_mnt() nor is_mounted() would let them through and bind-mounting a nsfsfd or a pidfd wouldn't work. Problem is that exception also admits a bind mount of such a file when it was lazily unmounted and is only kept alive by a file descriptor: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --rbind /proc/self/fd/3 /tmp/y With MS_REC or AT_RECURSIVE copy_tree() doesn't stop at the unmounted mount. It copies every mount that stayed attached to it as well. So if you have a bunch of overmounts over the nsfsfd or the pidfd the whole unmounted stack is copied. That's a bug. So refuse to walk an unmounted tree. Copying its root alone stays possible. So a bind mount of a namespace that is gone can still be recreated from a file descriptor on the old one. The file descriptor pins that mount and its root and __has_locked_children() only reads the direct children which don't leave the parent's list without namespace_sem. The internal mounts carry MNT_NS_INTERNAL instead of NULL and are still walked. Copying an unmounted tree recursively fails with EINVAL. Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs") Fixes: ef4144ac2dec ("pidfs: allow bind-mounts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-4-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit bfe0c4283bfa9955309d8cfa71fe4fd4778643ec Author: Leo Li Date: Tue Sep 29 17:32:32 2026 -0400 drm/amd/display: Fix direct scanout alpha on some DRM_FORMATs commit 7744262f5d63f9faa4d59dec127ae1c8b2d56495 upstream. [Why] DM was declaring it's own list of has_alpha DRM formats to check against for enabling alpha blending, when the format->has_alpha already does that for us. The self-declared list missed some has_alpha formats, causing direct-scanout planes with such formats to appear opaque. [How] Drop the self-declared list, instead use the format->has_alpha field directly. Signed-off-by: Leo Li Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit 9ecdac91ed43d836683d5daa467f4907405420e2) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 75dd88dcbf465f782fa90ec7188050bd3683b4f5 Author: Mikhail Gavrilov Date: Thu Oct 1 21:13:07 2026 +0500 drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locks commit 16c64495859f13f75602f439588883f2a4a4d6a6 upstream. Reading or writing a register through the amdgpu_regs2 debugfs file with GRBM bank selection, which umr does for every banked access (a single "umr -b x x x -r " is enough, as is the wave dump with "-O halt_waves"), makes lockdep report a circular locking dependency, after which lockdep stays off until reboot: WARNING: possible circular locking dependency detected umr/63306 is trying to acquire lock: ffff8882cf4b8350 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x9b/0x140 but task is already holding lock: ffff8881aec010d0 (&amdgpu_grbm_lock_key){+.+.}-{4:4}, at: amdgpu_debugfs_regs2_op.isra.0+0x20d/0xd00 [amdgpu] ... Chain exists of: &mm->mmap_lock --> &amdgpu_srbm_lock_key --> &amdgpu_grbm_lock_key ... __might_fault+0xc5/0x140 amdgpu_debugfs_regs2_op.isra.0+0x441/0xd00 [amdgpu] full_proxy_write+0x10e/0x1d0 vfs_write+0x1d0/0xf50 ksys_write+0x116/0x250 amdgpu_debugfs_regs2_op() and amdgpu_debugfs_process_reg_op() call get_user()/put_user() for every dword while holding grbm_idx_mutex or srbm_mutex, and pm.mutex if requested, so a fault there takes mmap_lock inside those locks. The lock hierarchy in amdgpu_lockdep.c puts srbm_mutex and grbm_idx_mutex below notifier_lock, which amdgpu_cs_submit() takes with the BO reservations held, and dma_resv_lockdep() orders the reservations inside mmap_lock. So mmap_lock is outside grbm_idx_mutex and srbm_mutex, and these two debugfs paths nest it the other way round. The copies under the locks are as old as the bank selection in both files; commit 1d0f5838b126 ("drm/amdgpu: Add lockdep annotations for lock ordering validation") only made them visible to lockdep. Copy the user buffer in before any of the locks is taken and the result out after all of them are dropped, as amdgpu_debugfs_wave_read(), amdgpu_debugfs_gpr_read() and amdgpu_debugfs_gprwave_read() already do. The buffer is sized by the count passed to read() or write(), so an access larger than PAGE_SIZE is now rejected with -EINVAL; umr reads and writes one register at a time. A fault on the user buffer of a write now fails with -EFAULT before any register is written, instead of after a partial write. Fixes: 566281595037 ("drm/amd/amdgpu: Add bank selection for MMIO debugfs (v3)") Fixes: 37df9560cd3e ("drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)") Acked-by: Christian König Acked-by: Tom St Denis Reviewed-by: Vitaly Prosyak Signed-off-by: Mikhail Gavrilov Signed-off-by: Alex Deucher (cherry picked from commit ccf9e35ed6811f2c25ba6368e7dc6481da17159d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 802bb8123385d6cb433ed0c34b996736917a89ef Author: Alex Deucher Date: Fri Sep 25 09:16:26 2026 -0400 drm/amdgpu: make Mac FB workaround generic commit c7f44ec5c4ec760e74351f1843dcb8322f67cbf6 upstream. Rather than adding a case of every chip where this is seen just check if the FB is at 0 and the ssid is apple. This should cover all chips which fall into this case. Tested-by: Ayhan Çiçek Signed-off-by: Alex Deucher (cherry picked from commit c54e4d10507722398dc90cf3c532e50b86cf425a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 11b6193c8841a052b7907006ffb1e02468b1448e Author: Vitaly Prosyak Date: Tue Sep 29 20:18:26 2026 -0400 drm/amdgpu: serialize vblank counter reads against GPU reset commit 1a6023edfbb5673f55fab6348f135fb3b1428ea5 upstream. The vblank counter callback reads display registers and scanout position without holding reset_domain->sem. During GPU recovery, display commit work can call the callback while reset owns the semaphore for writing. The hardware access then triggers the lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets TAINT_WARN when lockdep is enabled. Try to acquire the reset semaphore for reading before accessing the hardware, and hold it across the counter and scanout-position reads. If reset is already in progress, return DRM's cached software vblank count instead. This avoids blocking behind reset and avoids accessing display hardware while it is being reset. The cached count is less accurate than the hardware count, but is used only when reset prevents a safe hardware read. This addresses the reset-time warning from this vblank path; it does not suppress or fix unrelated lockdep warnings. Cc: Christian König Cc: Alex Deucher Cc: Harry Wentland Cc: Sunpeng Li Signed-off-by: Vitaly Prosyak Reviewed-by: Sunpeng Li Signed-off-by: Alex Deucher (cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cd52c0230f26dc963dfd53369298fab30c884a19 Author: Haojie Li Date: Fri Oct 2 10:29:27 2026 +0800 drm/amdkfd: fix dma_buf reference leak in get_dmabuf_info commit e6895021a328594368a2a19406a53ffca1ce51c7 upstream. When kzalloc fails for metadata_buffer in amdgpu_amdkfd_get_dmabuf_info(), the function returns -ENOMEM directly without calling dma_buf_put(), leaking the dma_buf reference obtained earlier via dma_buf_get(). Fix both issues by: - Adding an error check after the first amdgpu_bo_get_metadata() call - Replacing the direct return with r = -ENOMEM and goto out_put to ensure dma_buf_put() is called on all error paths Fixes: f54ce9e8cbd3 ("drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl") Signed-off-by: Haojie Li Signed-off-by: Alex Deucher (cherry picked from commit ffa699553332f8caf8688d312279ddcea9e3c141) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6f2025e54bb27cec7b6bfb33fe44f00498f63078 Author: Saleel Kudchadker Date: Thu Sep 24 23:52:19 2026 +0000 drm/amdkfd: align SDMA doorbell base for shader doorbell writes commit f145d5b3f740de05d85257acdc82f6877180f5c6 upstream. On GC 9.4.3, 9.4.4 and 9.5.0, doorbell writes issued from shaders are routed to an SDMA engine at 32-byte (4 doorbell index) granularity. SDMA engine doorbell ranges are 10 indices apart, so the range of every odd engine starts 2 indices into a 4-index block that begins in the previous engine's range. A shader ringing the doorbell of a queue on an odd engine therefore rings the previous engine instead. The intended queue never sees the doorbell, so its work stalls and the application hangs. Align the per-engine doorbell base up to a 4-index boundary on these ASICs. Each engine only uses 4 of its 10 indices, so the aligned base plus the queue offset stays within the engine's range. Even engines are already aligned, so only the doorbell IDs of odd-engine queues change. Only doorbells rung by the device itself are routed this way. Doorbell writes from the host, including the kernel's own SDMA rings, are not affected. The doorbell ID of an SDMA queue is saved in CRIU checkpoints and checked again on restore. A checkpoint taken before this change that contains an SDMA queue on an odd engine will fail to restore with -EINVAL. This is intentional: the restored process still holds the old doorbell address, so accepting the stale ID would bring back the same stall. Tested on MI300X with a shader-rung SDMA doorbell test: queues on odd engines hung before this change and complete with it. v2: use u32 instead of uint32_t for the new locals (checkpatch) v3: name the routing granularity, use dev->node_id, document the layout invariants, describe impact v4: express the granularity in doorbell indices, drop unrelated cleanups, explain the CRIU restore behavior, add test note Fixes: 6df442a03d1a ("drm/amdgpu: add new doorbell assignment table for aqua_vanjaram") Signed-off-by: Saleel Kudchadker Reviewed-by: Felix Kuehling Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit ee1379e6d7da47bdf7a8d5b89c2d1b28473701fb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a046cd60ff3f4a8c8e672b3b18902682c1f91731 Author: Fan Wu Date: Tue Sep 15 09:51:03 2026 +0000 drm/vc4: drain the hangcheck timer and works on V3D unbind commit 94cf5971b1d04c6382437387c4dc3836cc7a1437 upstream. Nothing stops the hangcheck timer that submitted jobs arm, or the job_done_work that the render-done interrupt queues, at teardown: vc4_irq_disable() cancels only overflow_mem_work, and vc4_gem_destroy() runs from the drm-managed release, after vc4_v3d_unbind() has already uninstalled the V3D interrupt and cleared vc4->v3d. A timer still armed by then reads V3D registers through the NULL vc4->v3d pointer, and the late callbacks run on the vc4_dev embedding them after it has been freed. Drain them in vc4_v3d_unbind(): shut the timer down and cancel reset_work before the interrupt is taken down, because its vc4_irq_reset() re-enables it, then flush job_done_work so that completions queued at teardown still release their jobs. This issue was found by an in-house static analysis tool. Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") Cc: stable@vger.kernel.org # 6.2+ Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260915095103.156007-1-fanwu01@zju.edu.cn Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 51b56bad96fd20127034f660b337c00317c65151 Author: Gyeyoung Baek Date: Thu Oct 1 22:39:13 2026 +0900 drm/imagination: Size page table preallocation by device address commit 789f290b2e81d42820bddcb4010ffbc2ae2ded54 upstream. Commit 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") passed the device address to pvr_mmu_op_context_create(), but the preallocation is still sized from device_addr + sgt_offset with an exclusive end. The offset into the object's pages has no place in a device-virtual range, and the exclusive end allocates one table too many when the range ends on a table boundary. Count the tables from device_addr and the inclusive end of the range. The new calculation does not take page table indices into account. This fixes another issue with the previous implementation, where the difference between start and end indices could underflow when a mapping crossed a page table boundary. This would lead to the driver preallocating a huge number of MMU pages, exhausting system memory and triggering an out of memory panic. Fixes: 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Gyeyoung Baek Reviewed-by: Brajesh Gupta Reviewed-by: Alessio Belle Cc: stable@vger.kernel.org [Alessio: add paragraph to point out OOM bug being fixed, cc stable] Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-2-f58254e5dfb8@gmail.com Signed-off-by: Alessio Belle Signed-off-by: Greg Kroah-Hartman commit 60f58da15f8c8e39706c564f9251de3626636dce Author: Krzysztof Karas Date: Thu Sep 10 08:13:29 2026 +0000 drm/i915/gt: Unmask interrupts only when ACTIVE is true commit 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb upstream. There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() callback -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE] WITH INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0] WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa() -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [check ACTIVE] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW], then: 3) rps_work() executes from the workqueue and may satisfy "(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a new value after previous intel_rps_unpark() event), so it jumps to "out" label, bypassing intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq(); 4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms, then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and emits "RPM wakelock ref not held during HW access" tainting kernel. Commit 3e7abf814193 ("drm/i915: Extract GT render power state management") dropped the "if (rps->interrupts_enabled)" guard that gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in intel_rps_park() before rps_stop_timer() and rps_disable_interrupts(). Skip unmasking when RPS is no longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late worker to unmask interrupts while the GT is parked Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16562 Cc: stable@vger.kernel.org # v5.5+ Assisted-by: GitHub-Copilot:claude-opus-5 Assisted-by: GitHub-Copilot:gpt-6-astra Signed-off-by: Krzysztof Karas Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260910081329.3300417-1-krzysztof.karas@intel.com (cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit b1c357131fc467c579f65e9a9d1fdc1a6273ae1d Author: Krzysztof Karas Date: Fri Sep 11 06:11:45 2026 +0000 drm/i915/gem: Prevent overstepping exec array boundary commit ebe162db655881a38de43301151ff7ac940602b5 upstream. It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow(): 1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under "out" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array. To amend this problem, ensure that relocation cleanup uses the original exec object count, excluding the VMAs appended by the command parser. Fixes: 8e4ba491b0ba ("drm/i915: Parse command buffer earlier in eb_relocate(slow)") Signed-off-by: Krzysztof Karas Assisted-by: GitHub-Copilot:gpt-6-astra Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260911061145.3535489-1-krzysztof.karas@intel.com (cherry picked from commit 2a0158925fb943c7ba8f3216e2734952128defc9) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 245d811ee6f164ded251d10dc9027e4424a18761 Author: Sajal Gupta Date: Tue Sep 22 14:10:08 2026 +0530 drm/gud: don't keep a connector without a CRTC as connector_state commit 71ec70ea26e399eb8371fe9d2d5bf5dab09570fb upstream. If the 'for_each_new_connector_in_state()' loop finishes without hitting the break, connector_state is left pointing at the last connector visited, which has no CRTC, instead of staying NULL. That skips the "if (!connector_state)" fallback below the loop, which looks up the active connector when the state contains none. The function then carries on with a connector that is not driven. Fix by resetting connector_state to NULL for each connector visited that has no CRTC, so that it is NULL when none was found and the fallback runs. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260902123254.36987-1-sajal2005gupta@gmail.com?part=1 Signed-off-by: Sajal Gupta Acked-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260922084026.15481-1-sajal2005gupta@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3b303696f61461b3569019d7fcac6a646652b2b4 Author: Nguyen Ngoc Thang Date: Sun Sep 27 14:54:34 2026 +0700 drm/fb-helper: defer setup when fbdev_probe() fails, not just on -EAGAIN commit 755c94d178b7e972bb766199d34e4ba4f63a89eb upstream. __drm_fb_helper_initial_config_and_unlock() calls drm_client_modeset_probe() first, which already fills in each mode_set->mode/num_connectors for every connected output, and only afterwards calls drm_fb_helper_single_fb_probe() to create fb_helper->fb and wire it into those mode_sets via drm_setup_crtcs_fb(). If drm_fb_helper_single_fb_probe() fails with anything other than -EAGAIN (e.g. dev->driver->fbdev_probe() itself fails), the function bails out before drm_setup_crtcs_fb() runs and before setting fb_helper->deferred_setup. The client is left with mode_sets that have a mode and connectors but mode_set->fb == NULL, and nothing marks this fb_helper as needing a retry. __drm_fb_helper_restore_fbdev_mode_unlocked() only skips committing when fb_helper->deferred_setup is set, so a later .restore() call (drm_lastclose() on process exit, in this report) commits the stale mode_set through drm_client_modeset_commit() -> drm_client_modeset_commit_atomic() -> __drm_atomic_helper_set_config(), which hits WARN_ON(!set->fb). Mark fb_helper->deferred_setup on any drm_fb_helper_single_fb_probe() failure, not just -EAGAIN, so restore keeps skipping the commit until a later hotplug event successfully re-probes and re-populates mode_set->fb. The real error code is still returned to the caller unchanged. Reported-by: syzbot+ca23c8570669ead78867@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ca23c8570669ead78867 Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup") Cc: stable@vger.kernel.org Signed-off-by: Nguyen Ngoc Thang Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260927075434.72658-1-ngocthang2710.1999@gmail.com Link: https://patch.msgid.link/20260917154743.1621-1-shechenglong@xfusion.com Signed-off-by: Greg Kroah-Hartman commit 3fd5164bdb04635caa7942ddb554b0ec699a9433 Author: Palla Raghunath Date: Fri Oct 2 08:07:52 2026 +0100 Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown commit 08e90633377f1b2567ab5ad6810b74c552246a07 upstream. syzbot hit a NULL pointer dereference in rfcomm_dev_shutdown() when an RFCOMM tty is closed. rfcomm_dev_add() puts the new device on rfcomm_dev_list first and only then registers the tty device and saves it in dev->tty_dev. If that registration fails, dev->tty_dev is never set at all. The device can be looked up in the meantime, so an open() of /dev/rfcommN gets through rfcomm_tty_install() and attaches to it. When that tty is closed again, rfcomm_dev_shutdown() uses dev->tty_dev without checking it: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] RIP: 0010:rfcomm_dev_shutdown+0x48/0xb0 net/bluetooth/rfcomm/tty.c:131 Call Trace: tty_port_shutdown+0x1bf/0x220 drivers/tty/tty_port.c:372 tty_port_close+0x4e/0x150 drivers/tty/tty_port.c:705 tty_release+0x359/0x1670 drivers/tty/tty_io.c:1718 __fput+0x418/0xa50 fs/file_table.c:512 rfcomm_dev_destruct() already copes with a NULL dev->tty_dev. Add the same check to rfcomm_dev_shutdown(), so the tty device is only moved when it was actually registered. Fixes: cad348a17e17 ("Bluetooth: Implement .activate, .shutdown and .carrier_raised methods") Reported-by: syzbot+4a807caf7680652d53b6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4a807caf7680652d53b6 Cc: stable@vger.kernel.org Signed-off-by: Palla Raghunath Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c3f76b025cbbb0ab47310dbe7de18092d89f2a99 Author: Maxim Skokov Date: Tue Sep 15 10:00:46 2026 +0300 Bluetooth: RFCOMM: free the skb when the DLC has no owner commit 9d1afbf60ed53c5b051cd124153e0ae3078c8b93 upstream. rfcomm_recv_data() hands the skb to d->data_ready() and returns 0 without freeing it, so the callback owns the skb from that point on. The tty implementation frees it when the DLC has been detached from its device: static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) { struct rfcomm_dev *dev = dlc->owner; if (!dev) { kfree_skb(skb); return; } The socket implementation returns without freeing it, and the skb is leaked. A connected DLC can have no owner: rfcomm_sock_destruct() clears d->owner, while the DLC itself stays on the session until it is closed. Data frames that arrive in that window still find d->state == BT_CONNECTED in rfcomm_recv_data() and are handed to the callback, one leaked skb each. The leak does not stop on its own either. The remote runs out of credits only once RFCOMM_RX_THROTTLED is set, and for a socket the only place that sets it is rfcomm_sk_data_ready() itself, below the return. rfcomm_process_dlcs() keeps granting credits, so the remote keeps sending and the leak keeps growing. Free the skb, as the tty side does. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Mikhail Gavrilov Closes: https://lore.kernel.org/linux-bluetooth/CABXGCsPe5wykd8Aj-hm+SJ7SGQyb8yoGNnx3XDpPmBathj+EGg@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Maxim Skokov Assisted-by: Claude:claude-opus-5 Reviewed-by: Mikhail Gavrilov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 7ed7e038b520cf0dfa12d61c2caddb95e2f6922d Author: Iaroslav Voitovych Date: Thu Sep 24 19:11:58 2026 +0200 Bluetooth: MGMT: Fix status of pending commands flushed on power off commit 86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc upstream. cmd_complete_rsp() receives a struct cmd_lookup and, for a pending command that has no cmd_complete callback, falls through to cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so the status sent comes from the first byte of match->sk's representation, not from match->mgmt_status. commit f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") changed the callers' data from &status to &match and updated the cmd_complete branch to match->mgmt_status, but left the fall-through passing data unchanged. In mgmt_index_removed() match->sk is NULL, so every such command is answered with status 0x00 (Success) instead of MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too, unless a Set Powered command was pending: then settings_rsp() has stored that command's socket in match->sk, and the byte sent comes from the socket pointer. Either way the status the caller set, MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device is being unregistered), is lost. Pass the status the callers set. This was seen on a QCA9377 laptop: bluetoothd's Start Discovery, pending when the adapter was powered off, was answered with Command Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the zero-length success. BlueZ master has since added the length check on that path ("adapter: Fix crash on short start discovery reply", BlueZ a734b06059cb), but userspace should still be told Not Powered, not Success. Tested on Ubuntu 7.0.0-31 with a virtual controller (hci_vhci): power off is held in HCI Write Scan Enable while a Start Discovery is submitted, and the flush answers it with status 0x00 before this change and 0x0f (Not Powered) after. Fixes: f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") Cc: stable@vger.kernel.org Signed-off-by: Iaroslav Voitovych Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1adcfe232c0f58890c2538211a841100ad0512bd Author: Chengfeng Ye Date: Mon Oct 5 15:50:31 2026 +0800 Bluetooth: ISO: Serialize concurrent connect calls commit e32d80293a0e1a160d5e5101daa8c82148c07510 upstream. iso_sock_connect() checks the socket state before taking the socket lock and drops the lock again before setting up a connection. Two callers can both pass the admission check while the socket is open or bound. Caller A can copy its destination for route selection, then caller B can replace the socket destination before A binds or connects the CIS. A then uses B's destination with the route selected for its own request. B can also proceed after A attaches a connection and sets BT_CONNECT. For deferred BIS setup, B can bind a second BIS and overwrite iso_pi(sk)->conn, leaving the first connection's reference and conn->sk back-pointer stranded. Concurrent CIS connects can likewise replace the socket's connection. Later teardown only detaches the current connection, so a callback on the old connection can race with socket release and access a freed socket. KASAN reported: BUG: KASAN: slab-use-after-free in iso_sock_hold+0xf7/0x1b0 Call Trace: iso_sock_hold+0xf7/0x1b0 iso_conn_del+0x7b/0x1d0 iso_connect_cfm+0x186/0x16a0 hci_conn_failed+0x154/0x280 hci_abort_conn_sync+0x3dc/0x7d0 hci_cmd_sync_work+0x173/0x300 Allocated by task 121: sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100 Freed by task 121: kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260 Check admission under the socket lock and mark the connect operation in progress before publishing its destination. Keep that flag set across route lookup and connection setup, rejecting another connect with -EBADFD before it can change the destination or attach a connection. Clear the flag after either helper returns, including on failure, so a failed setup can be retried. A separate flag is needed because the socket lock must be released before acquiring the HCI device lock, while BT_CONNECT requires an attached connection. Keep the existing state transitions and the deferred CIS completion through iso_sock_recvmsg(). Reject an existing socket attachment in __iso_chan_add() before taking a new reference or publishing either pointer, so every caller preserves the connection association. Keep the same-socket, same-connection success case for deferred CIS setup. Reject an attached socket before BIS setup so a reusable BIS is not claimed before the attachment is rejected. In CIS setup, reject a different HCI connection before iso_conn_add() and drop the per-attempt HCI hold directly. An unowned iso_conn may still carry another reference after detachment, so its destruction cannot be relied on to release that hold. iso_listen_bis() creates a fresh PA HCI/ISO pair under the device lock, so the temporary iso_conn_put() frees the ISO candidate and drops its HCI hold on rejection. iso_conn_ready() uses a freshly allocated, unpublished child with no connection, making the socket-side rejection unreachable. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Suggested-by: Pauli Virtanen Assisted-by: GPT-6 Astra Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 559e4d2b6f83aaa96061659cc7104b7a0293f9ef Author: Chengfeng Ye Date: Mon Oct 5 00:25:48 2026 +0800 Bluetooth: ISO: Reject concurrent BIS listener setup commit 555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3 upstream. iso_sock_listen() drops the socket lock before calling iso_listen_bis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BT_BOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BT_LISTEN. __iso_chan_add() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites iso_pi(sk)->conn, leaking the connA reference and leaving connA->sk intact. Socket teardown follows connB, so later events on connA can cause a stale socket access. Recheck BT_BOUND and require iso_pi(sk)->conn to be NULL after taking both the HCI device and socket locks in iso_listen_bis(). The connection check also covers the interval between attachment and publication of BT_LISTEN. Reject a competing setup with -EBADFD through the existing unlock path before allocating another connection. A recorded KASAN report from an instrumented kernel shows: BUG: KASAN: slab-use-after-free in iso_sock_hold+0x119/0x1f0 Call Trace: iso_sock_hold+0x119/0x1f0 iso_conn_del+0xe4/0x270 hci_disconn_complete_evt+0x351/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 93: sk_prot_alloc+0x113/0x220 sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100 Freed by task 93: kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260 sock_close+0x10/0x20 Fixes: 168e28305b87 ("Bluetooth: iso: Fix circular lock in iso_listen_bis") Cc: stable@vger.kernel.org Assisted-by: GPT-6 Astra Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 76f2e2665697340ac719e7ff1bf148dd014e55c1 Author: Chengfeng Ye Date: Mon Oct 5 00:24:42 2026 +0800 Bluetooth: hci_sock: Serialize dead-device detachment commit 381a0925c556a8d91a80a9b9e3e86651d60ffee3 upstream. Rebinding an HCI socket after its controller is unregistered can race monitor control replay and crash the kernel. hci_sock_bind() clears hci_pi(sk)->hdev and drops the device reference under only the socket lock, whereas send_monitor_control_replay() holds hci_sk_list.lock for reading. Replay can observe a non-NULL hdev, then bind can clear it and drop the last reference before create_monitor_ctrl_open() reads hdev->id. This can cause a NULL pointer dereference if the pointer is reloaded, or a use-after-free if the old pointer is retained. The kernel reported: KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] RIP: 0010:create_monitor_ctrl_open+0x579/0x800 Call Trace: hci_sock_bind+0xd96/0x1190 __sys_bind+0x166/0x200 __x64_sys_bind+0x6d/0xb0 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The same missing serialization lets hci_send_to_sock() select a socket for the old device and queue its frame after bind has detached the socket or installed a new binding. Take hci_sk_list.lock for writing when clearing the device pointer and resetting the socket state. This waits for existing replay and delivery readers to finish before detachment and prevents later readers from using the old binding. Keep hci_dev_put() outside the critical section because the final device release can sleep. Fixes: e04480920d1e ("Bluetooth: defer cleanup of resources in hci_unregister_dev()") Cc: stable@vger.kernel.org Assisted-by: GPT-6 Astra Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c9b00a9ebefc3a91bd1839f50ebef41afcde80cc Author: Runyu Xiao Date: Wed Sep 30 15:44:53 2026 +0800 Bluetooth: btintel_pcie: use managed IRQ teardown commit 25016fe8c1ed0fccae107bd629089139ffbafe08 upstream. The PCIe driver registers its MSI-X handlers with devm_request_threaded_irq(), but remove() uses free_irq() directly. The devres actions then retain registrations and attempt to release them again during device cleanup. Use devm_free_irq() for the remove path and for already registered vectors when a later setup request fails. This removes the managed resource at the same time as the IRQ is released and keeps MSI-X vector teardown ordered after IRQ ownership is gone. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Runyu Xiao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit f350186edef70bb3b3c6a7661366b5f72f335c54 Author: Karl Mehltretter Date: Mon Sep 7 21:07:50 2026 +0200 riscv: fix load_unaligned_zeropad() fixup for RV32 commit d4f25b097e46d82718bb737d4540c99b7ab0a408 upstream. The fixup for load_unaligned_zeropad() runs when REG_L crosses into an unmapped page. REG_L is lw on RV32 and ld on RV64, but the fixup assumes an 8-byte load: it rounds the address down to 8 bytes and derives the shift from three address bits. On RV32, a load starting in the last three bytes of a mapped page selects the word four bytes earlier and shifts it by 40, 48, or 56 bits, more than the register width. The caller gets earlier bytes instead of the string tail followed by zeroes. This affects RV32 MMU kernels built with RISCV_EFFICIENT_UNALIGNED_ACCESS=y, which selects DCACHE_WORD_ACCESS and lets dcache name hashing and comparison and strscpy() use this path. Derive the alignment and offset masks from sizeof(data) instead of a fixed 8. This makes RV32 use the correct source word. RV64 code is unchanged: the complete extable.o is byte-for-byte identical before and after. Fixes: d0fdc20b0429 ("riscv: select DCACHE_WORD_ACCESS for efficient unaligned access HW") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Jisheng Zhang Link: https://patch.msgid.link/20260907190750.26303-1-kmehltretter@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 6639735367a7d491977e9e5e7afc50b489d81d83 Author: Ziyi Guo Date: Thu Oct 1 13:57:11 2026 +0000 riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp commit 4d0697f192975dab5985e921989be1d85cf580e9 upstream. Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel shadow call stack pointer (gp) only when the trap came from userspace. It made that decision with scs_load_current_if_task_changed, which compares the trap-time tp (read back from sscratch into s5) against the current tp: beq \prev, tp, _skip_scs scs_load_current _skip_scs: tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (¤t) before trapping makes the comparison succeed (can achieve by brute force with KASLR enable under our test), so the kernel skips scs_load_current and keeps running with the gp that userspace left in place. Under CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and load_global_pointer is a no-op, so the compiler-emitted "sd ra, -8(gp)" / "ld ra, -8(gp)" in every non-leaf function then write to, and return through, an attacker-controlled address -- an unprivileged kernel arbitrary-write and control-flow-hijack primitive. The poisoned gp is saved to task_struct.scs_sp on return, so the reload is skipped on every subsequent entry as well. Decide "came from userspace" from the hardware sstatus.SPP bit (already in s1 at this point) instead of from tp, mirroring the check that ret_from_exception already uses a few instructions later. SPP is written by hardware on trap entry and cannot be forged from U-mode. Legitimate behaviour is unchanged: user entries (SPP=0) reload the task shadow call stack, nested kernel entries (SPP=1) skip it. Fixes: d1584d791a29 ("riscv: Implement Shadow Call Stack") Signed-off-by: Ziyi Guo Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20261001135711.934152-1-guoziyi114@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit bf148af252a850d36ce467767800aa5c823edecb Author: Runyu Xiao Date: Thu Sep 10 17:24:05 2026 +0800 scsi: qedi: Initialize callback state before registration commit 85de8b3a5eaa23d153aff4c7c83dddbc949064c9 upstream. qedi_get_protocol_tlv_data() can be called asynchronously by QED after qedi_ops->register_ops(). It takes stats_lock and reads ll2_mtu, but __qedi_probe() currently registers the callback before initializing the mutex and assigning the default MTU on the normal probe path. Initialize the callback-visible state before registering qedi_cb_ops. Keep the recovery path from reinitializing state because it reuses the existing qedi context. Fixes: 3cc5746e5ad7 ("scsi: qedi: Initialize the stats mutex lock") Cc: stable@vger.kernel.org Assisted-by: LLM Codex Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260910092405.1300129-1-runyu.xiao@seu.edu.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e3a8837aed75bbf303e201245b6b4587b94f97aa Author: Shawn Lin Date: Mon Sep 21 14:52:50 2026 +0800 pmdomain: rockchip: propagate subdomain add errors commit 4c0d69d677cf5b0065ebbb3ceb8ba66fddbec630 upstream. rockchip_pm_add_subdomain() ignored the return value of its recursive call, so a failure deeper in the hierarchy was silently dropped and probe still succeeded with an incomplete domain tree. Fixes: 6be05b5ec161 ("soc: rockchip: power-domain: add support for sub-power domains") Signed-off-by: Shawn Lin Reviewed-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cbb1c0f7af55703c1715b73d9d2abba4b1b09c1a Author: Shawn Lin Date: Mon Sep 21 14:52:51 2026 +0800 pmdomain: rockchip: fix clock leak on domain probe failure commit d8b3847770661b7109146e6479eeadcdab9cecf0 upstream. When of_clk_get() failed in the middle of the loop, the references of the clocks acquired so far were leaked instead of being released by the error path. Fixes: d909072d0521 ("soc: rockchip: power-domain: use clk_bulk APIs") Signed-off-by: Shawn Lin Reviewed-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 076aae32642b6cc3614571cb129b7eade5cf5669 Author: Shawn Lin Date: Mon Sep 21 14:52:52 2026 +0800 pmdomain: rockchip: don't ignore clock lookup errors on attach commit 4c66c423593e26273ea0d644906ed007630c6f6d upstream. rockchip_pd_attach_dev() treated every of_clk_get() error as the end of the clock list, so a clock that exists but is not available yet (e.g. -EPROBE_DEFER) was silently skipped and the device ended up without pm_clk management. Only -ENOENT means there are no more clocks. Fixes: 7c696693a4f5 ("soc: rockchip: power-domain: Add power domain driver") Signed-off-by: Shawn Lin Reviewed-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2ccbf4457812f11b26b732555d01c063da94b79c Author: Ming Qian Date: Mon Sep 21 19:03:34 2026 +0900 pmdomain: imx8m-blk-ctrl: Serialize power on/off across sibling domains commit 51c2db3ef0cb89a49ab7f47a40efd5d5b074ce8d upstream. On i.MX8MP the VPU blk-ctrl exposes G1, G2 and VC8000E as three separate genpds, each serialized only by its own genpd lock, so their power_on and power_off callbacks can run concurrently on SMP. The sequences are not independent: they share the VPUMIX bus domain, the VPU_NOC and the ADB400 handshake. On power up the GPC cannot ack-verify the ADB400 handshake - the ack only completes once blk-ctrl sets the bus clk-en bit - so it just waits a fixed delay instead of polling hskack. A sibling transition landing inside another domain's reset window disturbs that shared clock and handshake timing, the victim's reset does not take effect, and its block registers read back all zeros: the decoder times out or the encoder fails its format check. Serialize the blk-ctrl reset sequence with a per-blk-ctrl mutex; the driver deliberately avoids a genpd hierarchy, so the genpd core gives no cross-sibling serialization. Fixes: a1a5f15f7f6c ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl") Signed-off-by: Ming Qian Reviewed-by: Frank Li Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 66b7da589b2ce44a02b8387c6160e9254685f34f Author: Ridham Khurana Date: Wed Sep 30 10:53:25 2026 +0000 regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4 commit 2f15518682c779b1014552cb2ccb4a2052f85f27 upstream. The TPS65224 BUCK2, BUCK3 and BUCK4 descriptors pass 4 as n_linear_ranges, but tps65224_bucks_2_3_4_ranges[] only has two entries, covering selectors 0x00-0x45. The linear range helpers loop over n_linear_ranges entries, so any lookup of a selector above 0x45 reads past the end of the array and treats whatever follows it as two more ranges. This happens on the normal registration path when the core checks the voltage constraints against every selector. TPS652G1 uses the same descriptors and is affected too. Use ARRAY_SIZE() so the count always matches the table. Fixes: 00c826525fba ("regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators") Cc: stable@vger.kernel.org Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260930105333.3522412-1-khurana.ridham222@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1fb0d58fd363b439b4faf08a16ee6ae38b575cd4 Author: Abhishek Ojha Date: Tue Sep 1 21:07:01 2026 -0400 regulator: ltc3676: don't read the write-only HRST and CLIRQ registers commit 28c2388ee24cdbefbcc458fa41ef7bffaaa1cc83 upstream. HRST (0x1e) and CLIRQ (0x1f) are write-only command strobes. Writing HRST triggers a hard reset of the chip and writing CLIRQ clears the interrupt; reading them returns nothing useful, and the read itself fires the command. The result is that a plain register dump resets the board: cat /sys/kernel/debug/regmap/2-003c/registers walks every readable register, hits HRST, and the board reboots. Split the callback back in two so HRST and CLIRQ stay writable but are no longer readable. The readable range is left unchanged (LTC3676_BUCK1 ... LTC3676_IRQSTAT). Fixes: 37b918a034fe ("regulator: Add LTC3676 support") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Ojha Link: https://patch.msgid.link/20260902010701.3360310-1-Abhishek.ojha@savoirfairelinux.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8cae1605be8a047ae3a62df07b9474d61462c4f6 Author: Shao-Fu Chen Date: Fri Sep 18 18:10:46 2026 +0800 optee: register TEE devices only once fully initialized commit c108feca0a096f8db25d1b69130035025e9e936d upstream. optee_probe() called tee_device_register() on both the client and the supplicant device before the rest of struct optee had been initialized. tee_device_register() calls cdev_device_add(), which does two things at once: it creates /dev/tee0 and /dev/teepriv0, and it links the device into the tee class so that class_find_device() can find it. From that moment on the device is reachable both from user space via tee_open() and from kernel space via tee_client_open_context(). The only gate in teedev_open() is tee_device_get(), which merely checks that teedev->desc is non-NULL, which was already set by tee_device_alloc(). Therefore, there is effectively no gate at all. A context opened in that window can run against a struct optee where - optee->call_queue.mutex is not initialized by optee_cq_init() - optee->supp mutex and completions is not initialized by optee_supp_init() - optee->rpmb_dev_mutex is not initialized yet, - the message argument cache is not initialized by optee_shm_arg_cache_init() - optee->ctx is still NULL Any open session or invoke during this window takes uninitialized mutexes and dereferences a NULL pointer. Fix it by moving both tee_device_register() calls down to the point where all of struct optee is set up. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Cc: stable@vger.kernel.org Signed-off-by: Shao-Fu Chen [JW: adding fixes and cc] Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit b872de585edff534056c65ba30970b68499fca14 Author: Denis V. Lunev Date: Tue Sep 29 09:25:19 2026 +0200 openvswitch: fix soft lockup in the netlink flow dump commit aaaaf87ea99b8766c9a8aa0e71aa42e6bc8a5320 upstream. A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked. ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats->lock with spin_unlock_bh() once per CPU that has touched the flow. Every release is a local_bh_enable(), and each one runs the pending softirq backlog in the dumping thread's own context. The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box's packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU's softirq engine. It never sleeps and it has no reschedule point, so under voluntary preemption nothing can take the CPU away from it: neither the ksoftirqd the kernel woke to take the work over, nor the stopper thread the softlockup detector dispatches to refresh its timestamp. Hold BH off across the whole callback instead, the way ctnetlink_dump_table() does, so the nested spin_unlock_bh() stop draining softirqs. The loop already runs under rcu_read_lock() and cannot sleep. What it gives up is preemption under CONFIG_PREEMPT, since a BH-off region is not preemptible outside PREEMPT_RT. The region stays short: the skb caps the flows one callback emits, and empty buckets cost no skb space but are each visited once per dump, as the cursor only moves forward. The table grows on insert and shrinks only on flush, so the walk is bounded by the largest flow count the datapath has held. The softirq backlog the callback used to absorb has no bound at all. Fixes: 63e7959c4b9b ("openvswitch: Per NUMA node flow stats.") Cc: stable@vger.kernel.org Signed-off-by: Denis V. Lunev Reviewed-by: Ilya Maximets Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8e577550a860954768ab75da4ab68f030e4d0498 Author: Karl Bonde Torp Date: Tue Sep 29 16:25:00 2026 +0200 nvme: fix swapped ZRASF zone state values for full and read only commit 564e46d9f6e87912effa03f123d37a511d520f09 upstream. The Zone Management Receive command Zone Receive Action Specific (ZRASF) reporting option values for the Full and Read Only zone states are swapped compared to the NVM Express Zoned Namespace Command Set Specification, Revision 1.5, Figure 35: - 5h lists the zones in the ZSF:Full state. - 6h lists the zones in the ZSRO:Read Only state. The nvmet ZNS backend uses these constants to map the ZRASF value received from the host to a block layer zone condition when filtering zones in Report Zones. Because of the swap, a host asking for full zones was given the read only zones, and a host asking for read only zones was given the full zones. Swap the values of NVME_ZRASF_ZONE_STATE_FULL and NVME_ZRASF_ZONE_STATE_READONLY to match the specification. Fixes: aaf2e048af27 ("nvmet: add ZBD over ZNS backend support") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Signed-off-by: Karl Bonde Torp Signed-off-by: Andreas Hindborg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 3dcde4e9983e4f67c20cbe5f061bba7a89c21771 Author: Fredrik Nyberg Date: Fri Oct 2 14:28:57 2026 +0200 net: usb: ax88179_178a: fix rx frame length for non-last packets commit 9b6c20f788472d2042717a3c2f1bc60b2b77083e upstream. Commit 4ce62d5b2f7a ("net: usb: ax88179_178a: stop lying about skb->truesize") replaced skb_clone() with a copy into a new skb for every packet of a bulk-in transfer except the last one. The copy skips the 2-byte IP alignment pseudo header but still copies pkt_len bytes, and pkt_len includes that header. Each of these frames is therefore delivered with two extra trailing bytes: the 0xeeee pseudo header of the next slot when the frame ends on an 8-byte boundary, or slot padding otherwise. The last packet is still trimmed to pkt_len - 2. IPv4 and IPv6 trim the extra bytes, so most traffic is unaffected. Anything that relies on the frame length is not. MACsec takes the ICV from the last 16 bytes and drops every such frame as InPktsNotValid. In our setup that was 0.2-1.2% of received MACsec frames, depending on how many frames shared a transfer, including service discovery multicast. Allocate and copy pkt_len - 2 bytes, like the last-packet path. Fixes: 4ce62d5b2f7a ("net: usb: ax88179_178a: stop lying about skb->truesize") Cc: stable@vger.kernel.org Signed-off-by: Fredrik Nyberg Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261002-ax88179-rx-len-v1-1-f01a2a295079@volvocars.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fa0c27d9e17ee2e46d4b8274a6fde706f0d6725e Author: Daniel Machon Date: Wed Oct 7 17:03:15 2026 +0200 net: sparx5: free the matchall entry on destroy commit 2b82e16d6084cbc651e3c902198f1945408ee1a5 upstream. sparx5_tc_matchall_replace() allocates a struct sparx5_mall_entry for every offloaded matchall filter and adds it to sparx5->mall_entries. sparx5_tc_matchall_destroy() removes the entry from the list, but never frees it, so the entry of every deleted mirror and goto matchall filter is leaked. Free the entry after unlinking it. The leak was discovered by an AI code review agent, and reproduced with kmemleak on a lan969x EV board (EV23X71A) by repeatedly adding and deleting matchall mirror and goto filters. With the fix, kmemleak no longer reports the leak. Cc: stable@vger.kernel.org Fixes: 1ede4acf045c ("net: sparx5: add bookkeeping code for matchall rules") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20261007-sparx5-matchall-kfree-net-v1-1-c8918685b337@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5f19b9cfff79508e8cb09be40d014cb0807f3854 Author: Josef Bacik Date: Wed Oct 7 17:29:34 2026 +0000 net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() commit ab9414ed70bd783e902a85c350620dee269bcb2b upstream. When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent. Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset(). Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20261007-b4-skb-copy-csum-stale-bytes-v1-1-adbbde033fb3@toxicpanda.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7d81f92ecdfe029effe718ef82fb1771e84851ee Author: Sebastien Royen Date: Wed Oct 7 10:05:57 2026 +0200 net: dsa: microchip: fix KSZ8765 fiber detection commit fc13ba44da197a186f2f4d77c5b7d73d0f99f053 upstream. The KSZ8765 is similar to the KSZ8795 but has two fiber ports. KSZ8_PORT_STATUS_0 is used to detect fiber mode. It is currently defined as 0x08, which is the Global Control 6 MIB Control register and has bit 7 defined as Flush Counter. Set KSZ8_PORT_STATUS_0 to 0x18, which is the Port 1 Status 0 register where bit 7 is the Fiber Mode bit. This issue was discovered when upgrading an embedded device from kernel 5.10 to 6.16. The device was using a KSZ8765 device tree configuration and the corresponding hardware, but during boot the kernel incorrectly detected it as a KSZ8795. The relevant boot messages were: ksz-switch spi0.0: found switch: KSZ8795, rev 0 ksz-switch spi0.0: Device tree specifies chip KSZ8765 but found KSZ8795, please fix it! Cc: stable@vger.kernel.org Fixes: 91a98917a883 ("net: dsa: microchip: move switch chip_id detection to ksz_common") Reviewed-by: Nicolai Buchwitz Signed-off-by: Sebastien Royen Link: https://patch.msgid.link/20261007080557.15719-1-sebastien.royen@armadeus.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2fb87c6025f90191516bee3ce14b42eb3e1cfed7 Author: Zixuan Chai Date: Sun Sep 27 01:04:39 2026 +0800 net: bridge: avoid recursive multicast port cleanup commit 5158353121bae4f552cb677ce8c5c3ef52f93a0d upstream. br_multicast_sg_del_exclude_ports() removes automatically added STAR_EXCL port groups by calling br_multicast_del_pg(). For S,G entries, that deletion calls back into br_multicast_sg_del_exclude_ports(), so a large number of STAR_EXCL ports consumes one kernel stack frame per port and can hit the stack guard page. Keep the complete port-group deletion path for cleanup, but suppress the S,G exclude-port cleanup while that helper is already walking the same entry. Normal deletion callers retain the existing behavior. Fixes: 8266a0491e92 ("net: bridge: mcast: handle port group filter modes") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Zixuan Chai Signed-off-by: Ren Wei Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1512e3714b3946bda75a160a34f22a51710daa43 Author: Chengfeng Ye Date: Thu Oct 8 16:44:44 2026 +0800 net/smc: protect clcsock lifetime in smc_getname commit 64a6b36b0e1855288080bc5f89769f27d6dc03c8 upstream. smc_getname() dereferences smc->clcsock without holding clcsock_release_lock. Link-group termination can release the CLC socket through smc_close_active_abort() while the SMC socket is still open, for example after shutdown(SHUT_WR). A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sock_release() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket. KASAN reported the following with test-only timing instrumentation: BUG: KASAN: slab-use-after-free in smc_getname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smc_getname+0x19e/0x1b0 do_getsockname+0xe5/0x170 __sys_getsockname+0x8c/0x100 Allocated by task 95: sock_alloc_inode+0x1e/0x280 sock_alloc+0x3d/0x240 __sock_create+0x7e/0x430 smc_create+0x121/0x240 Freed by task 0: kmem_cache_free+0xcc/0x340 rcu_core+0x50a/0x1850 Last potentially related work creation: evict+0x446/0x6c0 smc_clcsock_release+0xa8/0xd0 smc_close_active_abort+0x26a/0x3a0 __smc_lgr_terminate.part.0+0x137/0x2e0 Hold clcsock_release_lock across the pointer check and the getname() callback to serialize with smc_clcsock_release(). Return -EBADF if the CLC socket has already been released, preserving the existing peer state check and the callback's return value otherwise. Fixes: b03faa1fafc8 ("net/smc: postpone release of clcsock") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Mahanta Jambigi Reviewed-by: Dust Li Link: https://patch.msgid.link/20261008084444.787449-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be Author: Quchaosheng Date: Mon Sep 28 19:31:08 2026 +0800 net/packet: guard the ll header push in packet_rcv_spkt() commit 28bc1ef699610ee09ce3d46a00552f5a0a0144bd upstream. packet_rcv_spkt() restores the link layer header with skb_push(skb, skb->data - skb_mac_header(skb)); That subtraction is only meaningful when the device actually has a link layer header. packet_rcv() and tpacket_rcv() both wrap it in dev_has_header(), which is also the predicate the block comment at the top of the file states the restore in terms of; packet_rcv_spkt() does not. commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") introduced the helper and changed the two call sites, and this one stayed behind. A device without a visible ll header can leave skb->mac_header at the 0xFFFF sentinel that __alloc_skb() initialises it to. A CAN skb does: init_can_skb() sets pkt_type and ip_summed but does not reset the headers, and commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") dropped the skb_reset_*_header() calls that used to be there. skb_mac_header() is then 0xFFFF, the length becomes a large negative number and skb_push() reports it through skb_under_panic() -- from softirq context, so it is a full system panic even with panic_on_oops=0: skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60 Call Trace: skb_push+0x38/0x40 packet_rcv_spkt+0xe1/0x170 __netif_receive_skb_core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt The socket type is reachable: packet_create() accepts SOCK_PACKET alongside SOCK_RAW and SOCK_DGRAM behind the same CAP_NET_RAW check, and neither the socket length nor a capability check keeps it away from a CAN interface. The missing skb_reset_*_header() calls in init_can_skb() are a regression in their own right and are being fixed separately, but a packet socket should not turn a link layer that did not initialise its mac header into a kernel panic. Guard the push the way the other two receive paths do. Tested on v7.3-rc5 under QEMU with a slcan device on a pty, which is the driver RX path: vcan does not reproduce it, because can_send() resets the headers on the way out. One SOCK_PACKET socket bound to can0 and one frame written into the line discipline panics an unpatched kernel with the trace above; the same image with this patch prints no panic and powers off normally. Both kernels are this tree, defconfig plus CONFIG_CAN_SLCAN=y, differing only in this hunk. Fixes: d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") Cc: stable@vger.kernel.org Signed-off-by: Quchaosheng Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260928113108.2127215-1-quchaosheng000406@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 03244b8713d044425db5dbee08037ecd79b684f9 Author: Guangshuo Li Date: Wed Sep 16 00:19:47 2026 +0800 mmc: sdhci-sprd: disable runtime PM on remove commit e1c6c10a6a70a69e29b04fcc1ebe4b9bcbc7a49a upstream. sdhci_sprd_probe() enables runtime PM, while sdhci_sprd_remove() does not perform the corresponding runtime PM cleanup. The probe failure path disables runtime PM before disabling the clocks, but the normal remove path directly disables clocks that are also managed by the runtime PM callbacks. If the device is runtime suspended, those clocks may already be disabled. Resume the device before removal, disable runtime PM and drop the temporary runtime PM reference before disabling the clocks. This issue was found by manual code inspection. Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Baolin Wang Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f37e0367ad6f2147a0b37564b442b7a25bec0d23 Author: Yibo Tan Date: Tue Sep 15 22:44:57 2026 +0800 mmc: mtk-sd: Cancel request timeout work on remove commit b38af5386a74416e898955443f2e26547b358cb2 upstream. The driver queues req_timeout while a request is active. msdc_request_done() uses cancel_delayed_work(), which does not wait for a timeout callback that has already started. The timeout callback calls mmc_request_done(), which wakes the request waiter, and then continues to use host->dev_comp and check the SDIO IRQ. During unbind, msdc_drv_remove() can return and the managed mmc_host can be freed before the callback finishes. KASAN reported use-after-free accesses in msdc_request_done() and msdc_recheck_sdio_irq() in each of three unbind tests. The same tests completed without a kernel diagnostic after this change. Call cancel_delayed_work_sync() after mmc_remove_host() has stopped new requests and before the driver releases the host resources. Fixes: 208489032bdd ("mmc: mediatek: Add Mediatek MMC driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1f52a3b0515da962d3791956f38fbfb3b617c6eb Author: Guangshuo Li Date: Wed Sep 16 00:13:10 2026 +0800 mmc: cavium-thunderx: destroy slot platform devices on remove commit 29ee8cf18a21b02cd0b2e35f741b61cd1fe3e14e upstream. thunder_mmc_probe() creates host->slot_pdev[i] with of_platform_device_create(), while thunder_mmc_remove() does not destroy the child platform devices. The probe failure path removes each MMC slot and destroys its associated platform device, but the normal remove path only removes the MMC slot. As a result, the child platform devices remain registered after the ThunderX MMC controller is removed. Destroy each slot platform device during removal after cleaning up the corresponding MMC slot, matching the probe failure cleanup path. Keep an extra device reference around of_platform_device_destroy() as done in the existing error path. This issue was found by manual code inspection. Fixes: 166bac38c3c56 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4780940bf66dd52c1b59e44047a07113d7eb3fe8 Author: Guangshuo Li Date: Tue Sep 15 23:57:24 2026 +0800 mmc: cavium-octeon: destroy slot platform devices on remove commit 0f4d4424fc1d651ec3fa63a0a8060ba9087eb0ec upstream. octeon_mmc_probe() creates host->slot_pdev[i] with of_platform_device_create(), while octeon_mmc_remove() does not destroy the child platform devices. The probe failure path removes each MMC slot and destroys its associated platform device, but the normal remove path only removes the MMC slot. As a result, the child platform devices remain registered after the Octeon MMC controller is removed. Destroy each slot platform device during removal after cleaning up the corresponding MMC slot, matching the probe failure cleanup path. This issue was found by manual code inspection. Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2c96d1a8324e7736e0f8a5790ecf39d36c2c4a82 Author: Mikulas Patocka Date: Wed Sep 23 12:40:16 2026 +0200 dm: fix reading free memory in do_resume commit c9417c1c5269e2bd0570fbe53e4ec03a8d31f008 upstream. When do_resume calls dm_table_get_mode(new_map), the call is done without holding any locks (it only holds a reference to the md). It may be possible that another concurrent ioctl on the same device will swap table after dm_swap_table and before dm_table_get_mode. In this case, dm_table_get_mode(new_map) reads freed memory. This race condition was triggered by syzbot. This commit fixes the race by reading mode of the new table before dm_swap_table. Note that new_map is also passed to dm_ima_need_measure, but this function doesn't attempt to dereference it, so this call should be safe. Note that this is not a security bug because only root can trigger it and the commonly used tools such as lvm or cryptsetup do not call the ioctls concurrently, so that they can't trigger it acceidentally. Signed-off-by: Mikulas Patocka Reported-by: syzbot+bdff1ecf726d2af66afd@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 13e551abb9b5894f4122661f5d3d310349e958ff Author: Ma Xinmeng <1564938642@qq.com> Date: Fri Sep 25 11:05:39 2026 +0800 dm-snap: reject the transient exception store for snapshot-merge commit fcbde6227fcc53c73f08c56b2539e462d545cac6 upstream. snapshot_merge_next_chunks() calls s->store->type->prepare_merge() without checking it. The transient store ("N") implements neither prepare_merge nor commit_merge, and snapshot_ctr() validates those callbacks only on the handover path (__validate_exception_handover()), so a directly constructed snapshot-merge calls a NULL prepare_merge on resume: snapshot_merge_resume -> snapshot_merge_next_chunks -> prepare_merge(...) commit_merge() is NULL for the same reason. Userspace only issues documented device-mapper ioctls (CAP_SYS_ADMIN); this is a misconfiguration the kernel must reject rather than oops on. Reject the combination in snapshot_ctr() at table-load time (-EINVAL), the same check the handover path already performs; this also covers the commit_merge() call site, which a guard local to the prepare_merge call would miss. Tested on Linux v6.6.157 KASAN: unpatched, the dmsetup reproducer oopses in snapshot_merge_next_chunks(); with this patch, the table load fails with -EINVAL and no oops. Also present on v6.6.145; still present on the linux-dm tree (555f3d7be91a) and on torvalds/linux master (62f4c998b297) as of 2026-09-22. Note that this is not a security bug because only root can trigger it. Signed-off-by: Ma Xinmeng <1564938642@qq.com> Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 962ce265fbf5d87afeb78cf19c12e083ab0ffeb8 Author: Ben Cressey Date: Tue Sep 15 00:39:10 2026 +0000 dm-crypt: reject the lmk IV mode with AEAD ciphers commit 3195e0daf590683992edb4eed32269e569e04924 upstream. A "capi:" table line that pairs an AEAD cipher with the lmk IV mode, for example "capi:gcm(aes)-lmk" with the integrity:28:aead option, causes an oops when it is loaded. lmk sets tfms_count to 64, but crypt_alloc_tfms_aead only allocates one transform, so crypt_setkey reads past the end of the tfms_aead array and calls crypto_aead_setkey on the values it finds there. lmk exists for compatibility with Loop-AES, which uses CBC, so refuse it with an AEAD cipher rather than allocate 64 AEAD transforms. The check cannot go in crypt_iv_lmk_ctr with the other lmk checks, because the IV constructor runs after crypt_set_key. Note that this is not a security bug because the memory corruption can only be triggered by root. Fixes: 33d2f09fcb35 ("dm crypt: introduce new format of cipher with "capi:" prefix") Cc: stable@vger.kernel.org Signed-off-by: Ben Cressey Assisted-by: LLM Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 5b599e28aeb3684772aef64f46cc6f25f4c67128 Author: Nguyen Ngoc Thang Date: Wed Sep 30 21:07:48 2026 +0700 memstick: rtsx_usb_ms: complete requests after eject instead of dropping them commit c96ca94425b076dc398d929366e378d1e22ec794 upstream. memstick_check() can pass its host->removing check just before rtsx_usb_ms_drv_remove() sets eject/removing. Its next request is then silently dropped: rtsx_usb_ms_request() skips schedule_work() once eject is set, and drv_remove's cancel_work_sync() can also cancel a queued handle_req before it picks the request up. Nobody completes card->mrq_complete. Once memstick core waits for requests without a timeout ("memstick: core: wait for request completion before freeing card"), this hangs removal: memstick_check() never returns and memstick_remove_host() blocks in flush_workqueue(): INFO: task kworker/u10:3:65 blocked for more than 20 seconds. Workqueue: kmemstick memstick_check __wait_for_common memstick_check INFO: task kworker/1:1:33 blocked for more than 20 seconds. Workqueue: usb_hub_wq hub_event __flush_workqueue memstick_remove_host rtsx_usb_ms_drv_remove Never drop a request. rtsx_usb_ms_request() always schedules handle_req, and handle_req fails requests with -ENOMEDIUM once eject is set, without touching the device. drv_remove flushes handle_req instead of cancelling it, and cancels it only after memstick_remove_host(), when no new request can arrive, so it cannot run on a freed host. The host_mutex drain in drv_remove is removed: handle_req always leaves host->req NULL when it finishes, so the drain never had anything to do, and it would now race with handle_req. Fixes: 99451dceeb5f ("memstick: Add realtek USB memstick host driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260924204142.607-1-rajojha047@gmail.com/ Signed-off-by: Nguyen Ngoc Thang Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 810580cf60edc75c9891c2de3225e4cda78e4d9f Author: Raj Ojha Date: Fri Sep 25 00:59:55 2026 +0530 memstick: core: wait for request completion before freeing card commit aa0a37b5024d921e96ac4f8f487c8bfbf1f1a582 upstream. In memstick_alloc_card() and memstick_set_rw_addr(), wait_for_completion_timeout() is used to wait for device identification and address configuration requests to complete. The memstick subsystem does not provide an abort or cancellation callback in struct memstick_host for in-flight requests. If wait_for_completion_timeout() expires (for instance, when a USB transfer or command retry is delayed), memstick_alloc_card() returns an error and frees the memstick_dev structure via kfree(card). However, the host controller driver (such as rtsx_usb_ms) is still running the request asynchronously in worker context. When the transfer eventually finishes, the driver writes into host->req->data, which points to memory inside the already freed card structure. This leads to a KASAN slab-use-after-free write: BUG: KASAN: slab-use-after-free in ms_read_bytes+0x8fe/0x990 Write of size 1 at addr ffff88813c188079 by task kworker/1:5/5239 Workqueue: events rtsx_usb_ms_handle_req Call Trace: ms_read_bytes+0x8fe/0x990 drivers/memstick/host/rtsx_usb_ms.c:450 rtsx_usb_ms_issue_cmd drivers/memstick/host/rtsx_usb_ms.c:477 [inline] rtsx_usb_ms_handle_req+0x557/0x1a00 drivers/memstick/host/rtsx_usb_ms.c:531 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560 kthread+0x373/0x450 kernel/kthread.c:436 Allocated by task 1662: memstick_alloc_card drivers/memstick/core/memstick.c:383 [inline] memstick_check+0x2c1/0x10d0 drivers/memstick/core/memstick.c:452 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 Freed by task 1662: kfree+0x20c/0x650 mm/slub.c:6792 memstick_alloc_card drivers/memstick/core/memstick.c:420 [inline] memstick_check+0x72b/0x10d0 drivers/memstick/core/memstick.c:452 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 Host controller drivers (rtsx_usb_ms, jmb38x_ms, tifm_ms, r592) already implement their own hardware and bus timeouts, and callers in mspro_block and ms_block already rely on wait_for_completion() unconditionally. Replace wait_for_completion_timeout() with wait_for_completion() in memstick_set_rw_addr() and memstick_alloc_card() so that the card structure is never freed while an asynchronous request is in flight. Fixes: baf8532a147d ("memstick: initial commit for Sony MemoryStick support") Reported-by: syzbot+ccffdf05833ebdaeae70@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ccffdf05833ebdaeae70 Cc: stable@vger.kernel.org Signed-off-by: Raj Ojha Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f99399b48e3edd6851fac34cd329bab9f1f33baf Author: 성병찬 Date: Wed Sep 30 13:18:01 2026 +0900 KEYS: Fix add_key() race with keyring restriction commit dd3ea3fcba7c75493760cdbccd35f029597e8d5e upstream. __key_create_or_update() snapshots keyring->restrict_link before taking the destination keyring's semaphore. keyring_restrict() installs a restriction while holding that semaphore. This allows a writer to observe no restriction, wait for the keyring owner to install a reject-all restriction and return successfully, and then link a key using the stale NULL snapshot. The writer only needs write permission on the destination keyring. Move the restrict_link read after __key_link_lock() and __key_link_begin(). The read and the subsequent restriction check are then serialized with restriction installation by keyring->sem. The race was reproduced on v7.2.8 in 19 executions where restriction installation returned before the link completed. All 19 linked the key despite the reject-all restriction. With this change, 312 executions reached the same ordering and every add_key() call failed with -EPERM. The issue was found by manual concurrency analysis assisted by AI-based analysis and independently verified with a QEMU reproducer and kernel instrumentation. Fixes: 5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring") Cc: stable@vger.kernel.org Signed-off-by: 성병찬 Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260930041802.6114-1-tjdqudcks0424@naver.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 86b13c1c89a26d6cbcf610ce7411b673616fb7fd Author: Karl Mehltretter Date: Sat Sep 12 11:54:40 2026 +0200 keys: finalize persistent keyring timeout after link attempt commit 25bf14f817168079f731975b8998fc2af380f29e upstream. When no keyring exists for the requested UID, KEYCTL_GET_PERSISTENT creates and registers one before linking it to the requested destination. The configured timeout is set only after the destination link succeeds. A destination restricted with KEYCTL_RESTRICT_KEYRING makes that link fail with -EPERM. With persistent_keyring_expiry set to 60 seconds, /proc/keys still reports the registered keyring's expiry as "perm". The failed call therefore leaves a quota-exempt keyring in the namespace's hidden register, where it may remain until namespace teardown. Rename the write-locked helper to key_get_or_create_persistent() and return the key reference through a result parameter. Return 0 when it creates a keyring and 1 when the retry finds an existing one. Return a negative error on failure. Another caller may create the keyring between the initial read-locked lookup and the retry under the write lock. Set the timeout after permission checking and linking. Do this on success, or on failure if the call allocated the keyring. This leaves a new keyring collectible after failure without starting its timeout while linking is still in progress. Cc: stable@vger.kernel.org # v5.10+ Fixes: f36f8c75ae2e ("KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://lore.kernel.org/r/20260912095440.79864-1-kmehltretter@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 6f5544f53f1e58ea8a49fb9f9158d5793b9205b0 Author: Tristan Madani Date: Mon Sep 28 16:04:25 2026 -0700 ice: fix metadata_dst refcount handling on representor teardown commit 58858b8f14803a7eeac297b3ce20f3b21bf2ff66 upstream. ice_eswitch_release_repr() uses metadata_dst_free() to release the representor's metadata_dst. metadata_dst_free() directly frees the underlying memory without checking the dst_entry refcount. When ice_eswitch_port_start_xmit() processes a packet, it takes a reference via dst_hold() and attaches the metadata_dst to the skb. If the representor is torn down while packets are still queued on the lower device (e.g. in a qdisc), the metadata_dst is freed while references are still held. Use dst_release() instead, which correctly decrements the refcount and only frees the object when all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set. Other drivers sharing this pattern (nfp, airoha, bnxt) already use dst_release() for their metadata_dst lifecycle. Fixes: f5396b8a663f7 ("ice: switchdev slow path") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Simon Horman Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260928230429.495442-5-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ca8aacdccd96b93c6d287a341295c28929a05424 Author: Mingming Cao Date: Fri Sep 25 11:05:30 2026 -0700 ibmveth: fix TX LTB and filter unwind on open-fail commit 84bec0bf035258a1073ffd6f6dc8ea61806aa7d4 upstream. out_free_buffer_pools reuses open()'s loop index for the TX LTB walk. After the pool unwind i is -1, so the TX buffers allocated earlier are leaked. request_irq() failure has the same leak. The TX-fail goto on that walk also skips dma_unmap of the filter list (pre-existing since the LTB was added). Rewrite the TX walk to real_num_tx_queues with a pointer check, and unmap the filter list before those frees. Fixes: d926793c1de9 ("ibmveth: Implement multi queue on xmit") Cc: stable@vger.kernel.org Signed-off-by: Mingming Cao Reviewed-by: Dave Marquardt Link: https://patch.msgid.link/d14314c2b10f125f5e578782484ba3cc50564d53.1790357373.git.mmc@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c54bbdf6f0731102a4bf7f5e4ee535b3ea415996 Author: Mingming Cao Date: Fri Sep 25 11:05:29 2026 -0700 ibmveth: h_free logical LAN on open-fail after register commit af0524bf4ce1a4cbd2946aa81751582951cfcab5 upstream. ibmveth_open() registers the logical LAN, then allocates the RX buffer pools. A pool failure jumps to out_free_buffer_pools without h_free_logical_lan(), so PHYP still owns the buffer-list page when it is unmapped. request_irq() failure already issued the hypercall before taking the same label. Move that h_free to the shared post-register unwind so both paths deregister before the buffer list is unmapped. Fixes: d43732ce021f ("ibmveth: properly unwind on init errors") Cc: stable@vger.kernel.org Signed-off-by: Mingming Cao Reviewed-by: Dave Marquardt Link: https://patch.msgid.link/7a56fbfb9e0674f011f4e310fbd7dfd8e67c30aa.1790357373.git.mmc@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f73ee2bd2293f8cc340061c5229395ace71fc2eb Author: Ridham Khurana Date: Wed Sep 23 11:39:02 2026 +0000 gpio: xilinx: fix runtime PM leak on request error path commit ff82fc3a4a1d417dee1229681cc5285986edb1fa upstream. pm_runtime_get_sync() leaves the usage counter incremented even when it fails, and xgpio_request() returns the error without dropping it. gpiolib does not call ->free() when ->request() fails, so xgpio_free(), which holds the only matching pm_runtime_put(), never runs. The reference is leaked and the controller can no longer runtime-suspend, so its clock stays enabled. Switch to pm_runtime_resume_and_get(), which only increments the usage counter on success. Fixes: 26b04774621e ("gpio: gpio-xilinx: Add support for suspend and resume") Cc: stable@vger.kernel.org Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260923113905.1409290-1-khurana.ridham222@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 655f48f526e5b8a80550cf6fbf6d21fb18f7d6ee Author: Vishal Badole Date: Fri Oct 2 17:02:03 2026 +0530 EDAC/amd64: Mask UMC chip select to the four implemented selects commit 7484bc43ba6b8e189b482db5b75e7842890a82b1 upstream. For DRAM ECC errors, the chip select value can be found in the MCA_SYND[ErrorInformation] field. ErrorInformation[2:0] was first documented in Zen1. The 3 bit field implied that up to 8 chip selects may be used. However, all Zen-based systems have only ever had up to 4 chip selects. So only bits [1:0] would contain a valid chip select value. Future systems are redefining the field to ErrorInformation[1:0]. This matches the existing 'up to 4 chip selects' implementations. And it frees up the extra bit for other decoding. Change the current chip select mask from 0x7 to 0x3 to prepare for the decode change. Fixes: 713ad54675fd ("EDAC, amd64: Define and register UMC error decode function") Suggested-by: Yazen Ghannam Signed-off-by: Vishal Badole Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Yazen Ghannam Cc: Link: https://patch.msgid.link/20261002113204.3358815-2-Vishal.Badole@amd.com Signed-off-by: Greg Kroah-Hartman commit 44edec72460b8ee980af191a02295d61f112f6b1 Author: Hui Peng Date: Wed Sep 30 04:46:11 2026 +0000 sctp: copy zeroed stats to user in sctp_getsockopt_pr_streamstatus() when !streamoute commit 538b529509c7ab0d909cb65bb7264edca1788d30 upstream. When an SCTP stream output extension structure (streamoute) has not yet been allocated, sctp_getsockopt_pr_streamstatus() sets the local stack variables params.sprstat_abandoned_unsent = 0 and params.sprstat_abandoned_sent = 0, but then immediately jumps to 'out:', bypassing copy_to_user(). As a result, when an uninitialized user buffer is passed to getsockopt(SCTP_PR_STREAM_STATUS), the kernel returns success (0) without copying the zeroed stats back to user space, leaving uninitialized data in the user buffer. Refactor the !streamoute check into an if-else chain so that when streamoute is NULL, params is zeroed and falls through to copy_to_user(), copying the zeroed stats to user space and setting retval = 0 once before returning. Tested in QEMU against Linux 7.3.0-rc3 using an uninitialized sctp_prstatus user struct passed to getsockopt(SCTP_PR_STREAM_STATUS) on a freshly created stream: on the unfixed kernel the user struct contains uninitialized stack garbage; whereas with this fix applied, getsockopt() copies zeroed stats into user space and returns 0. Cc: stable@vger.kernel.org Reviewed-by: Xin Long Signed-off-by: Hui Peng Fixes: f952be79cebd ("sctp: introduce struct sctp_stream_out_ext") Link: https://patch.msgid.link/20260930044611.204739-1-benquike@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a6da93c625b3557dd23ff6db45d2d1bafeae1565 Author: Stephen Smalley Date: Mon Sep 28 10:19:17 2026 -0400 selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts commit 28b7260548af3d35773477993ad4e4de41578dd7 upstream. When an NFSv4 filesystem exported with security_label is mounted a second time, sget_fc() returns the existing superblock and nfs_get_root() calls security_sb_set_mnt_opts() again on it. Since the superblock is already SB_INITIALIZED, selinux_set_mnt_opts() takes an early exit without setting SECURITY_LSM_NATIVE_LABELS in *set_kern_flags. nfs_get_root() then sees kflags without SECURITY_LSM_NATIVE_LABELS set and clears NFS_CAP_SECURITY_LABEL on the shared nfs_server, silently disabling per-file labeling for both the new and the original mount. Commit 3815a245b501 ("security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock") fixed the same problem in selinux_sb_clone_mnt_opts(). The reused-superblock path for a plain second mount now goes through sb_set_mnt_opts rather than sb_clone_mnt_opts, so it needs the same treatment: on both SE_SBINITIALIZED early exits, set SECURITY_LSM_NATIVE_LABELS in *set_kern_flags when the superblock was already using SECURITY_FS_USE_NATVE. Cc: stable@vger.kernel.org Closes: https://github.com/SELinuxProject/selinux-kernel/issues/69 Closes: https://github.com/SELinuxProject/selinux-kernel/issues/70 Closes: https://github.com/SELinuxProject/selinux-testsuite/issues/91 Closes: https://github.com/SELinuxProject/selinux-testsuite/issues/92 Fixes: eb9ae686507b ("SELinux: Add new labeling type native labels") Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 7656bd398a4bf4d05744d74df2c22483cfaf74ad Author: Christian Göttsche Date: Wed Sep 23 12:13:23 2026 +0200 selinux: fix data race on AVC latest_notif commit 1ca924044bf0de879a1648be93a56939652267d3 upstream. avc_policy_seqno() reads latest_notif without holding notif_lock, while avc_latest_notif_update() can update it under that lock. KCSAN reports these concurrent accesses during policy boolean updates and permission checks. Use READ_ONCE() for the lockless read and WRITE_ONCE() for the update. The spinlock continues to serialize the comparison and update against other writers. Reads made while holding notif_lock cannot race with a writer and can remain plain accesses. This marks both sides of the intentional concurrent access and constrains compiler transformations, without suppressing checking with data_race(). Cc: stable@vger.kernel.org Fixes: 788e7dd4c22e ("SELinux: Improve read/write performance") Reported-by: syzbot+a7f7cb0737bd91aa698c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a7f7cb0737bd91aa698c Signed-off-by: Christian Göttsche Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 9a80e38020e9d41bcbbd5eadc9bc10e23441b1d4 Author: Johannes Berg Date: Wed Oct 7 22:42:08 2026 +0200 Revert "wifi: libertas: reject short monitor TX frames" commit 9727d1c4e1c971fc42b049b645fdda6852758835 upstream. This reverts commit 13ff543e0b2c713aedeaadadde686686e949dc78. The 'goto free' just made things worse, causing a spinlock to be handled incorrectly. Revert this for now. Reported-by: Takashi Iwai Cc: stable@vger.kernel.org Fixes: 13ff543e0b2c ("wifi: libertas: reject short monitor TX frames") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f17e70206a1e763fcca2578a8db3c4eed0f843a9 Author: Chengfeng Ye Date: Tue Sep 29 00:12:46 2026 +0800 tipc: hold a reference to nodes found by link name commit 17e73bae400f6a434dc006e3bee92c94cf781954 upstream. tipc_node_find_by_name() returns a node after dropping its RCU read lock without taking a reference. The LINK_SET, LINK_GET and LINK_RESET_STATS handlers then lock and access the node, racing with timer-driven cleanup of a down peer. Generic netlink serialization does not exclude the node timer. The following interleaving can leave a handler using a freed node: CPU 0: find the node under RCU and release the node read lock CPU 1: tipc_node_timeout() clears the links and unlinks the down node CPU 1: drop the list and timer references, queuing tipc_node_free() CPU 0: leave the RCU read-side critical section CPU 1: complete the grace period and free the node CPU 0: acquire the node lock through the stale pointer LINK_SET also uses the node's media address after releasing the node lock, when passing queued packets to tipc_bearer_xmit(). KASAN on v7.3-rc5 reported: BUG: KASAN: slab-use-after-free in _raw_read_lock_bh Write of size 4 at addr ffff88807e06f008 by task poc/92 Call Trace: _raw_read_lock_bh kernel/locking/spinlock.c:287 tipc_nl_node_set_link net/tipc/node.c:2475 genl_family_rcv_msg_doit net/netlink/genetlink.c:1114 genl_rcv_msg net/netlink/genetlink.c:1209 netlink_rcv_skb net/netlink/af_netlink.c:2575 Allocated by task 0: tipc_node_create net/tipc/node.c:539 tipc_node_check_dest net/tipc/node.c:1196 tipc_disc_rcv net/tipc/discover.c:252 Freed by task 92: kfree mm/slub.c:6801 rcu_core kernel/rcu/tree.c:2919 Last potentially related work creation: __call_rcu_common.constprop.0 kernel/rcu/tree.c:3181 tipc_node_timeout net/tipc/node.c:814 Acquire a reference to the selected node with kref_get_unless_zero() before leaving RCU, returning NULL if the node has already been released. Release that reference on every caller exit after the last node access, including transmission in LINK_SET. Keep the existing link lookup order and locking so concurrent link removal still takes the existing error paths. Fixes: 6a939f365bdb ("tipc: Auto removal of peer down node instance") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260928161246.1895273-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit da9c16568bc79140a54c1f5fcf07a0305df47b37 Author: Yuqi Xu Date: Mon Sep 28 16:24:38 2026 +0800 tipc: destroy topsrv workqueues before closing connections commit 3acdd44385bc7e2e57605e073691ce69cc5a960d upstream. tipc_topsrv_stop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the conn_idr walk. That race produced several teardown failures: refcount_t addition on 0 from conn_get() on a connection whose release was blocked on idr_lock, a subsequent use-after-free in tipc_conn_close(), queue_work() on an already destroyed workqueue from the listener data-ready callback, and an RCU stall in tipc_topsrv_exit_net() while the walk spun under idr_lock. Clear srv->listener under idr_lock so it acts as a shutdown flag, skip queue_work() once it is NULL, destroy the workqueues to flush in-flight work, and only then close the remaining connections. Refuse tipc_conn_lookup() after that flag is cleared, and drop idr_lock when the teardown walk finds no connection, so an in-flight subscription event cannot pin idr_in_use while the walk holds the lock. v3 supersedes the narrower in-thread diff Tung Quang Nguyen posted on 2026-09-23. It keeps his teardown order and adds the lookup refusal and the empty-idr unlock. Fixes: c5fa7b3cf3cb ("tipc: introduce new TIPC server infrastructure") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 563d3564513496b9ce3b3ba7a5154427554d0f06 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 30 19:25:24 2026 +0900 tcp: reject net_iov in zerocopy receive mapping hints commit 8b1f0af1fd5fd113432233ed8a3862ee7c30a84f upstream. After copying a readable prefix, receive_fallback_to_copy() asks tcp_zerocopy_set_hint_for_skb() where page mapping can resume. If the next skb is unreadable, find_next_mappable_frag() passes its net_iov fragment to can_map_frag(). skb_frag_page() returns NULL for a net_iov, but can_map_frag() dereferences it in PageCompound(). A v7.2 KASAN run on a connected TCP socket with 64 readable bytes followed by a 4096-byte NET_IOV_DMABUF fragment reported: BUG: KASAN: null-ptr-deref in can_map_frag tcp_zerocopy_receive -> can_map_frag Kernel panic - not syncing: KASAN: panic_on_warn set The diagnostic inserted the net_iov directly because the test host has no devmem-capable NIC. Hardware end-to-end reachability remains untested and requires CONFIG_NET_DEVMEM plus a supported DMA-buf-bound RX queue. Reject all net_iov fragments before skb_frag_page(). This covers both DMABUF and IOURING net_iov types while leaving page-backed checks unchanged. With the guard, the same queue copied the readable prefix, returned a 4096-byte skip hint, and completed without a fault. Fixes: 9f6b619edf2e ("net: support non paged skb frags") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20260930102524.1659847-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 97890dbc8643075c4a86dc40e94a565a4db26a13 Author: Marek Szyprowski Date: Wed Sep 30 10:50:55 2026 +0200 swiotlb: fix default_swiotlb_limit() for non-growable default pool commit 911655ab1dfb9d526978a75df3b210132620d30a upstream. Commit ad96ce3252db ("swiotlb: determine potential physical address limit") changed default_swiotlb_limit() to return the maximum physical address that could ever be used by dynamically allocated pools, so that the value stays constant when CONFIG_SWIOTLB_DYNAMIC=y. However, io_tlb_default_mem.phys_limit is returned even when the default pool cannot grow, e.g. when swiotlb_init_remap() is called with a remap callback. This breaks Xen dom0 on x86: pci_xen_swiotlb_init() passes SWIOTLB_ANY and xen_swiotlb_fixup(), so phys_limit is set to the top of dom0 memory, although xen_swiotlb_fixup() makes the default pool below the 32-bit boundary. xen_swiotlb_dma_supported() then rejects 32-bit DMA masks, even though the bounce buffer is perfectly usable by such devices. Return phys_limit only if the default pool can actually grow, otherwise report the real end of the default pool, like in the !CONFIG_SWIOTLB_DYNAMIC case. Reported-by: Andreas Greve Reported-by: James Dingwall Fixes: ad96ce3252db ("swiotlb: determine potential physical address limit") Closes: https://lore.kernel.org/xen-devel/f74668db-52fd-4575-8372-7bfdf10d62ac@a-greve.de/ Cc: stable@vger.kernel.org Assisted-by: Claude Opus 5.5 (1M context) Tested-by: James Dingwall Link: https://lore.kernel.org/all/20261005070518.1590097-1-m.szyprowski@samsung.com/ Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit 9f3e9fe1b155e9b4572054d8d140586bc3512ecf Author: Sabrina Dubroca Date: Mon Oct 5 15:50:02 2026 +0200 strparser: make sure __strp_recv isn't running before tearing down the parser commit 0984ebc631792acf8fff105112ee74a6b8f1efcc upstream. The comment above strp_done() claims that if strp is stopped, strp_recv will no longer be called. That's only true if the caller has a mechanism (eg locking) to guarantee that strp_recv() calls that started before strp_stop() have completed by the time we call strp_done(). This adds a dummy lock_sock/release_sock pair to guarantee that any in-flight strp_recv() (which runs under either bh_lock_sock or lock_sock, depending if it's called from ->sk_data_ready or strp_work) has completed. Only espintcp can be affected by this race condition, but this patch makes sure no future user of strp can have the bug. This could crash on strp->sk ("general mode" of strp), but this mode has been here for 9 years and has never been used. It'll be gone soon, no point worrying about it. Switch the stopped/paused/etc bits to u8's to avoid races between strp_stop() and strp_pause/unpause(). A reproducer has been published and turns the possible UAF into an exploit [1]. Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/all/aZLn2Faeg1FB7XOf@v4bel/ Link: https://lore.kernel.org/all/aZgpkyTDU3aXe_V0@v4bel/ Link: https://github.com/m0x41nos/RustyTux [1] Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: stable@vger.kernel.org Signed-off-by: Sabrina Dubroca Reviewed-by: Hyunwoo Kim Link: https://patch.msgid.link/425d9d926709b542ed5331110c19fee4aee1f28d.1791206940.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e5dc7af9c3a5373ee7a84959126e7dfa9e4ad50d Author: Georgiy Osokin Date: Mon Sep 28 17:31:13 2026 +0300 tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper() commit b7f925fd5226deb953c8dcdc9677d3fcc2717c00 upstream. tee_dyn_shm_alloc_helper() derives nr_pages from a caller-supplied size and passes it to alloc_pages_exact() without checking it. For size == 0 nr_pages is 0, and alloc_pages_exact(0) calls get_order(0), which is documented as undefined and returns BITS_PER_LONG - PAGE_SHIFT. The page allocator then trips its order > MAX_PAGE_ORDER warning and fails the allocation; on a panic_on_warn kernel that ends the boot. This can be triggered by TEE_IOC_SHM_ALLOC with struct tee_ioctl_shm_alloc_data where size is 0. Reject a zero page count, as register_shm_helper() already does for the register path. Fixes: cf4441503e20 ("tee: optee: Move pool_op helper functions") Cc: stable@vger.kernel.org Cc: lvc-project@linuxtesting.org Signed-off-by: Georgiy Osokin Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit 99011a11c97340ef7290df7dc199305c73fab2f2 Author: Josef Bacik Date: Wed Oct 7 17:57:32 2026 +0000 xen/netfront: don't leak the skb when xennet_fill_frags() fails commit 93ccaf1c26e2133396173b76a071e59024daa622 upstream. When a response chain has more slots than fit in the skb's frags, xennet_fill_frags() returns an error and xennet_poll() jumps to its error path. That path moves what's left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it's never freed. Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends. Put the skb back on tmpq before taking the error path, like the xennet_set_skb_gso() failure just above it does. Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 729d576df89c7e4341e58c452f8890620a610ac2 Author: Pavankumar Kondeti Date: Mon Sep 28 09:18:56 2026 +0530 workqueue: Fix NULL current_pwq deref in chained work check commit 980db94e3eeefdd8a1c46f86412c33a7f7806f51 upstream. current_wq_worker() only tells us that %current is a kworker. It does not guarantee that the worker is currently executing a work item, as worker->current_pwq is populated only while process_one_work() is running the work function. is_chained_work() can be reached while queueing on a draining or destroying workqueue. If a kworker outside work-item execution reaches that path, current_wq_worker() returns a worker but worker->current_pwq is NULL, and the chained-work test can fault before it emits the intended warning. Guard the chained-work test with worker->current_pwq. A kworker without current_pwq is not executing work on the target workqueue, so the helper should return false and let the draining/destroying warning fire. Fixes: 8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()") Cc: stable@vger.kernel.org Signed-off-by: Pavankumar Kondeti Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit c76a80db593096edf2b3b3972f58b6342a8c6c04 Author: Jason A. Donenfeld Date: Thu Oct 8 14:59:16 2026 +0200 wireguard: noise: reject response consumption after intermediate initiation commit d0305f8d90029556260c6824b61c493c424eba9e upstream. Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A. Thread A Thread B Thread C down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() This seems basically impossible to hit in a meaningful way in practice, but ensure that it absolutely cannot happen by comparing the ephemeral private key that's on the stack with the latest one that the peer's handshake state has. Cc: stable@vger.kernel.org Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Reported-by: Jérémy Jean Signed-off-by: Jason A. Donenfeld Link: https://patch.msgid.link/20261008130124.724119-4-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 706122faadb959a59c5941c9686c14134da07c58 Author: Ramses de Norre Date: Thu Oct 8 14:59:15 2026 +0200 wireguard: queueing: preserve tstamp_type when encapsulating packet commit 65ab9de4bdd4c05d8277cfc20ae0b9f5aff60897 upstream. Sending traffic through a wireguard tunnel on a host using the fq qdisc fills the log with: fq: likely mono tstamp with tstamp_type 0 An skb carries a timestamp in skb->tstamp and, separately, a skb->tstamp_type field recording which clock that timestamp came from. The two have to agree. When wireguard encapsulates a packet it calls wg_reset_packet(), which clears the fields that must not leak from the inner packet into the tunnel packet. It does so in two steps: skb_scrub_packet(skb, true); memset(&skb->headers, 0, sizeof(skb->headers)); skb_scrub_packet() deliberately keeps skb->tstamp when it holds a monotonic timestamp: that value is the time the packet is scheduled to be sent, and the qdisc still needs it. The memset then zeroes skb->tstamp_type, because that field sits inside the headers group while skb->tstamp does not. The packet therefore leaves wireguard carrying a monotonic timestamp labelled as a realtime one. Nothing noticed until commit c4f796c4f16b ("net_sched: sch_fq: convert skb->tstamp if not monotonic"): fq used to assume every timestamp was monotonic. It now consults tstamp_type, spots the mismatch, warns, and falls back to treating the value as monotonic. Pacing still ends up correct, so the log spam is the actual problem. Save tstamp_type before the memset and restore it when encapsulating, next to the hash fields that are already carried over this way. When decapsulating it stays zeroed, which is right: an incoming packet's timestamp is a realtime receive timestamp. Fixes: d98d58a00261 ("net: Set skb->mono_delivery_time and clear it after sch_handle_ingress()") Signed-off-by: Ramses de Norre Reviewed-by: Toke Høiland-Jørgensen Reviewed-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Link: https://patch.msgid.link/20261008130124.724119-3-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2e0c8c60a11b3177e7432c71d41249e276a0825f Author: Michele Dionisio Date: Thu Sep 24 14:30:27 2026 +0200 wifi: brcmfmac: fix P2P device removal race in brcmf_detach() commit 08a3f02fea636e97a7422d1512f76dacdb5b0887 upstream. When the driver is removed while the user space process that created the P2P device (e.g. wpa_supplicant) is still exiting, the P2P device interface is removed twice and the kernel crashes. The two paths are: - wpa_supplicant, on exit, sends NL80211_CMD_DEL_INTERFACE for the P2P device. nl80211_del_interface() holds RTNL and the wiphy mutex and calls brcmf_p2p_del_vif(), which disables discovery and waits up to 1.5 s for BRCMF_E_IF_DEL. Then it calls brcmf_remove_interface(), which unregisters the wdev and frees the vif and the ifp. - brcmf_detach() sets the bus down, so BRCMF_E_IF_DEL never arrives, and calls brcmf_remove_interface(ifp, false) for the same ifp. brcmf_p2p_ifp_removed() reads ifp->vif and then blocks on rtnl_lock(). When brcmf_p2p_del_vif() releases RTNL, it calls cfg80211_unregister_wdev() on the wdev that was already unregistered and freed. The second list_del_rcu() of wdev->list faults on LIST_POISON2: brcmfmac: brcmf_p2p_del_vif delete P2P vif brcmfmac: brcmf_p2p_deinit_discovery enter brcmfmac: brcmf_p2p_del_vif P2P: GO_NEG_PHASE status cleared brcmfmac: brcmf_detach Enter brcmfmac: brcmf_bus_change_state 1 -> 0 brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed [1.5 s later, brcmf_p2p_del_vif() timed out] brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed Unable to handle kernel paging request at virtual address dead000000000122 Internal error: Oops: 96000044 [#1] PREEMPT_RT SMP pc : _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211] Call trace: _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211] cfg80211_unregister_wdev+0x10/0x1c [cfg80211] brcmf_p2p_ifp_removed+0x84/0xb0 [brcmfmac] brcmf_remove_interface+0x1f4/0x254 [brcmfmac] brcmf_detach+0x88/0x180 [brcmfmac] brcmf_sdio_remove+0x90/0x7b0 [brcmfmac] brcmf_sdiod_remove+0x20/0xa0 [brcmfmac] brcmf_ops_sdio_remove+0xbc/0x12c [brcmfmac] sdio_bus_remove+0x38/0x144 device_release_driver_internal+0x1e8/0x2c0 device_release_driver+0x14/0x20 brcmf_sdio_bus_remove+0x2c/0x40 [brcmfmac] brcmf_fwvid_unregister_vendor+0xd8/0x170 [brcmfmac] __exit_compat+0x18/0x418 [brcmfmac_cyw] __arm64_sys_delete_module+0x1ac/0x244 The log was taken with debug=0x406 on an i.MX 8M Plus board with a CYW55513 (Sona IF513) on SDIO. The driver is the Ezurio backport of brcmfmac from v6.18.22 on a 5.4-rt kernel. The code involved is the same in mainline. To reproduce: 1. Start wpa_supplicant on wlan0 and let it associate. It creates the P2P device (iw dev shows "type P2P-device"). 2. Stop wpa_supplicant and remove the driver without waiting for wpa_supplicant to exit: kill $(pidof wpa_supplicant) rmmod brcmfmac_cyw brcmfmac The crash is reproducible on that board. For the interface without a netdev (the P2P device), take RTNL and the wiphy mutex in brcmf_detach() before reading iflist, and remove it with locked=true. If brcmf_p2p_del_vif() runs first, brcmf_detach() finds the slot empty. If brcmf_detach() runs first, nl80211 does not find the wdev any more. The interfaces with a netdev are removed as before, because brcmf_del_if() takes RTNL on its own for the primary interface. Fixes: 9831bcb987df ("brcmfmac: Deleting of p2p device is leaking memory.") Cc: stable@vger.kernel.org Assisted-by: claude-opus-5-5 Signed-off-by: Michele Dionisio Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260924123027.4122909-2-michele.dionisio@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e4a0028b0d54b2c45e1dc8c0dd95fe3e9236f55b Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 00:13:10 2026 +0900 vsock/virtio: account only unread bytes in read_skb() commit a463f55c791b96cfd12df8b10ea737d45c80bb18 upstream. After a partial stream receive, rx_bytes tracks the unread suffix while buf_used and peer credit still cover the whole packet. virtio_transport_read_skb() dequeues that packet but passes pkt_len for both counters, underflowing rx_bytes. On a connected CID_LOCAL stream with an SK_SKB verdict, a 40-byte read from a 100-byte packet made SIOCINQ report -40, an empty recv return ELOOP, and poll report the empty socket readable. After verdict detach, receiving 40 bytes wrapped the counter to zero and hid those queued bytes until one more byte arrived. The fixed run kept the counter balanced and exposed all queued data immediately. This was found during an LLM-assisted manual source audit of VSOCK receive accounting while re-evaluating virtio_transport_read_skb() after CVE-2024-50169. Subtract only skb->len minus the VSOCK offset from rx_bytes. Retain the full packet length for buf_used and peer credit. Fixes: 45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets") Cc: stable@vger.kernel.org Reviewed-by: Luigi Leonardi Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20261001151310.4101006-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5978243a08769181d3adeffc00f48b9b73ba8652 Author: Ji-Ze Hong (Peter Hong) Date: Mon Aug 24 21:18:14 2026 +0800 usb: f81604: fix struct f81604_int_data size mismatch commit 7f85d1170575645f9f327062d78017a23b2714eb upstream. The struct f81604_int_data defines 9 bytes of interrupt data: - Byte 0: Status register (sr) - Byte 1: Interrupt register (isrc) - Byte 2: Interrupt enable register (ier) - Byte 3: Arbitration lost capture (alc) - Byte 4: Error code capture (ecc) - Byte 5: Error warning limit register (ewlr) - Byte 6: RX error counter (rxerr) - Byte 7: TX error counter (txerr) - Byte 8: Reserved (val) The hardware sends exactly 9 bytes for the interrupt endpoint. However, the struct was defined with __aligned(4) attribute which caused the compiler to pad the struct to 12 bytes. This causes a problem in f81604_read_int_callback() where the short URB check compares urb->actual_length against sizeof(*data). When sizeof(struct f81604_int_data) is 12 but the hardware only sends 9 bytes, the check fails and valid interrupt messages are discarded. This results in the driver only being able to transmit once because the TX complete interrupt is never processed. Fix this by removing the __aligned(4) attribute so the struct size matches the actual hardware data size of 9 bytes. Fixes: 7299b1b39a25 ("can: usb: f81604: handle short interrupt urb messages properly") Cc: stable@vger.kernel.org Reported-by: Dynetrex, Admin Closes: https://lore.kernel.org/all/A3834A07-5639-4779-844F-C5843DFC3928@dynetrex.com/ Signed-off-by: Ji-Ze Hong (Peter Hong) Acked-by: Greg Kroah-Hartman Tested-by: Drew Willey Link: https://patch.msgid.link/20260824-f81604-fix-v2-1-fc9be5581394@fintek.com.tw Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e5c3f3d8935ecc64c962fb66e6a86dbf79218f61 Author: Palla Raghunath Date: Sat Sep 19 00:43:39 2026 +0100 dm ioctl: don't let data_start run past the buffer commit 9b3fcf519d370df94a56f3b272d9eddffffa5be8 upstream. struct dm_ioctl has seven bytes of trailing padding, so the smallest buffer userspace is allowed to ask for, offsetof(struct dm_ioctl, data), is seven bytes shorter than sizeof(struct dm_ioctl). get_result_buffer() sets data_start to sizeof(struct dm_ioctl) without looking at how big the buffer actually is. Ask for the minimum and data_start ends up seven bytes past the end. Callers add it to data_size, and ctl_ioctl() copies that much back to userspace: BUG: KASAN: slab-out-of-bounds in _copy_to_user+0xad/0xd0 Read of size 312 at addr ffff8880169e4c00 by task repro-dm/140 ctl_ioctl+0x5e3/0xcb0 dm_ctl_ioctl+0x25/0x40 allocated 305-byte region [ffff8880169e4c00, ffff8880169e4d31) A DM_LIST_DEVICES with data_size set to 305 is enough to hit it, and the seven bytes that leak are whatever sat next to the allocation. Clamp data_start to the buffer size. Note that this is not a security bug because the out-of-bounds read can only be triggered by root. Reported-by: syzbot+48d935cf48a4a76be346@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=48d935cf48a4a76be346 Fixes: 76c072b48e39 ("dm ioctl: move compat code") Cc: stable@vger.kernel.org Signed-off-by: Palla Raghunath Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit b965977126a90e01825814c859ba4788691eddd3 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Oct 6 12:51:08 2026 +0900 cipso: adjust cached option offsets when removing CIPSO commit 6d25ffca055a77787c21a36b66c253f76239411b upstream. cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them. For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ip_forward_options() and __ip_options_echo() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage. Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and router_alert offsets when they follow CIPSO. cipso_len is the distance the first memmove() shifts those options. The later header move and network-header reset relocate the bytes and their offset base together. Fixes: 89aa3619d141 ("cipso: make cipso_v4_skbuff_delattr() fully remove the CIPSO options") Cc: stable@vger.kernel.org Reviewed-by: Ondrej Mosnáček Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Acked-by: Paul Moore Link: https://patch.msgid.link/20261006035108.3101440-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 452a435b74f7f598a343c51f7c89c5d2244384b6 Author: Wentao Liang Date: Wed Sep 16 17:16:10 2026 +0000 btrfs: scrub: fix local_root reference leak in scrub_print_warning_inode() commit 1fd742c7479961da6d0bb794ef8ac6b7b9442847 upstream. When paths_from_inode() fails, scrub_print_warning_inode() jumps to err without dropping the reference taken by btrfs_get_fs_root(), leaking a reference to the root every time path resolution fails while printing scrub warnings. Every other error and success path of the function drops the reference. Drop the reference on the paths_from_inode() failure path too. Fixes: 558540c17771 ("btrfs scrub: print paths of corrupted files") CC: stable@vger.kernel.org Reviewed-by: Qu Wenruo Signed-off-by: Wentao Liang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ca6f936632376361bd95eb24e63d0c06701e0747 Author: Michael Garland Date: Mon Oct 5 01:10:32 2026 -0600 ASoC: amd: yc: Add DMI quirk for Acer Aspire Go 15 (AG15-21P) commit d0cb7a7b2a490c381ad97f53155d02a748b60dea upstream. The Acer Aspire Go 15 (AG15-21P, board MDC Herbag2_MDU) has two PDM DMICs connected to the ACP. The BIOS does not set the AcpDmicConnected _DSD property, so the acp6x machine driver never registers the DMIC card. The existing Herbag_MDU entry does not match this board name, so add a DMI quirk for it. Tested on BIOS V1.11: the acp6x DMIC capture device is registered and records audio on both channels. Cc: stable@vger.kernel.org Signed-off-by: Michael Garland Link: https://patch.msgid.link/20261005-acp6x-herbag2-quirk-v1-1-a1f2683d758f@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 409f2985d7bad767f8cfbafb185f6b7ace789b5e Author: Karl Mehltretter Date: Sat Sep 26 21:13:25 2026 +0200 arm64: irq: exclude the softirq stack switch from KCOV commit a9cd14bfb0c113f1cd77be4349784663bec71bb4 upstream. On IRQ exit, __irq_exit_rcu() drops HARDIRQ_OFFSET before calling invoke_softirq(). The arm64 do_softirq_own_stack() wrapper and its ____do_softirq() trampoline run before __do_softirq() establishes softirq context, so KCOV records their PCs in the interrupted task's coverage buffer. They also run outside softirq accounting when local_bh_enable() reaches do_softirq(). The IRQ-exit coverage makes the KCOV boot selftest fail even after the scheduler and timer coverage leaks are suppressed. The generic softirq.o is already excluded from KCOV, but that exclusion does not cover the separately compiled arm64 wrappers. Exclude irq.o from KCOV instrumentation, as is already done for the arm64 entry code. This covers both wrappers even with compilers that lack the no_sanitize_coverage attribute. The softirq action functions remain instrumented for explicit remote coverage. Fixes: 8eb858c44b98 ("arm64: run softirqs on the per-CPU IRQ stack") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a5a34ed495fc46d979eea290131aac202c1f1788 Author: Krzysztof Furman Date: Fri Oct 9 15:47:10 2026 +0100 Input: xpad - add support for Corsair Novablade Pro commit f9282b8aa85a8c97c50d656db75feb6d76fc7cbe upstream. Add device IDs for the Corsair Novablade Pro leverless fight controller in both wired (0x2b1f) and 2.4 GHz receiver (0x2b2b) modes, and add Corsair's vendor ID to the Xbox 360 vendor match list. Outside of its PS4/PS5 modes the controller uses the Xbox 360 protocol (vendor-specific class, subclass 93, protocol 1) on interface 0, which xpad does not currently bind, so no gamepad device is created. The PS4/PS5 modes present a standard HID gamepad and already work with hid-generic. Tested on 7.2.5 with the 2.4 GHz receiver and wired. Assisted-by: Claude Opus 5.5 Signed-off-by: Krzysztof Furman Link: https://patch.msgid.link/20261009-xpad-corsair-novablade-v1-1-e58746bef99f@proton.me Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e44ec6b6d3c0b8ea089b589fa0cce49a4da66b89 Author: Haotian Zhang Date: Fri Oct 9 10:48:25 2026 -0700 Input: ati_remote2 - fix type confusion in device attribute handlers commit f321cc430c49b6c1be0d53f2ef19d8342d8029cc upstream. Previously, the channel_mask and mode_mask attributes were registered on the parent usb_device via sysfs_create_group(). When commit b20d6bf8014b ("Input: ati-remote2 - use driver core to instantiate device attributes") converted the driver to let the driver core manage them via dev_groups in struct usb_driver, the attributes moved to the bound usb_interface devices, but the show and store callbacks were not updated accordingly. As a result, the callbacks still invoked to_usb_device() on a device pointer belonging to a struct usb_interface, producing an invalid usb_device pointer. Use to_usb_interface() directly in the attribute handlers to obtain the interface and its driver data. Fixes: b20d6bf8014b ("Input: ati-remote2 - use driver core to instantiate device attributes") Assisted-by: DeepSeek-V4.1-Flash Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20261009040302.3087205-1-vulab@iscas.ac.cn Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7b112bd43f1172fb152e848570a957467008a5ae Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 8 14:29:23 2026 +0900 ipv6: do not warn on route notification size race commit c97426ec649d99596d8969e1a052c16b14b7b485 upstream. fib6_info_hw_flags_set() sizes the skb with rt6_nlmsg_size() and later fills it with rt6_fill_node(). With nexthop compatibility mode enabled, a concurrent replacement can grow the group between these independent snapshots. rt6_fill_node() can then legitimately return -EMSGSIZE, so the warning does not prove a sizing bug. Remove the warning. The existing error path still frees the skb and reports the error to listeners. Fixes: 907eea486888 ("net: ipv6: Emit notification when fib hardware flags are changed") Reported-by: Ido Schimmel Link: https://lore.kernel.org/netdev/20261007114003.GA1011260@shredder/ Suggested-by: Ido Schimmel Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/4012604727e5ba80b69ccd4d08796511397ddaef.1791423190.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 78a1cf5c54b2f795c81fedb530755a8d01cc84f0 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 8 14:29:22 2026 +0900 ipv4: do not warn on route notification size race commit e02a5b6588161673ef75a4bc5cdfb62bd493374d upstream. Commit 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") added asynchronous route notifications for hardware flag changes. fib_alias_hw_flags_set() sizes the skb with fib_nlmsg_size() and later fills it with fib_dump_info() while holding only RCU. With nexthop compatibility mode enabled, a concurrent replacement can grow the group between these independent snapshots. fib_dump_info() can then legitimately return -EMSGSIZE, so the warning does not prove a sizing bug. Remove the warning. The existing error path still frees the skb and reports the error to listeners. Fixes: 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") Reported-by: Ido Schimmel Link: https://lore.kernel.org/netdev/20261004082043.GB92032@shredder/ Suggested-by: Ido Schimmel Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/b7e203fc5867651cb67ef84aa03e082f0f76008e.1791423190.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ad1c9f1b98c92609e9bb2ae8f05916defc3b0a54 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 13:51:00 2026 +0900 ipv4: stop route notification sizing when nexthop group shrinks commit d3daa33c7af92e38f2274bbd2576f58bfbaf89e6 upstream. Commit 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") added an RCU-only fib_nlmsg_size() call for asynchronous hardware flag notifications. fib_nlmsg_size() checks fib_info_num_path() before each iteration, then fib_info_nhc() independently reloads nh->nh_grp. If RTM_NEWNEXTHOP replaces a group with fewer paths between those loads, fib_info_nhc() returns NULL and fib_nexthop_nlmsg_size() dereferences it. Stop sizing when the indexed path is absent. Nexthop groups are dense, so the current snapshot has no later path. Fixes: 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/1054fa46165bba1b473782fa41367804aa908e86.1790915964.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f91e472821e32f58b03eb631e20a67157e2b928b Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 13:50:59 2026 +0900 ipv4: stop exception dump when nexthop group shrinks commit 4f4afc07dcb2edd4f9afa36595373f8cdb9b58c2 upstream. Commit 4ce5dc9316de ("inet: switch inet_dump_fib() to RCU protection") allowed IPv4 FIB dumps to run concurrently with nexthop replacement. fib_dump_info_fnhe() uses fib_info_num_path() as the loop bound, then fib_info_nhc() independently reloads nh->nh_grp. If RTM_NEWNEXTHOP replaces a group with fewer paths between those loads, fib_info_nhc() returns NULL and the dump dereferences it through nhc_flags. Stop the walk when the indexed path is absent. Nexthop groups are dense, so the current snapshot has no later path. Fixes: 4ce5dc9316de ("inet: switch inet_dump_fib() to RCU protection") Reported-by: Ido Schimmel Link: https://lore.kernel.org/netdev/20261001170513.GA1657889@shredder/ Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/5bb7bd97411eb9db454464bf449107395e760f26.1790915964.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c60d17d6dd61adc761ac6f65a008fefbc54cbf87 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 13:50:58 2026 +0900 ipv4: stop PMTU walk when nexthop group shrinks commit 6619e01855e65ef35723685a557e3eb106f4ecf5 upstream. Commit 7d3f3b4367f3 ("net: ipv4: Cache pmtu for all packet paths if multipath enabled") made __ip_rt_update_pmtu() update every path. For nexthop objects, fib_info_num_path() and fib_info_nhc() independently load nh->nh_grp. RCU protects each group's lifetime but does not make the loads observe the same group. If replacement shrinks the group after the loop accepts an index, fib_info_nhc() returns NULL and update_or_create_fnhe() dereferences it. A deterministic probe only widened the existing window between the real operations. On v7.2, an RTM_NEWNEXTHOP replacement published a one-member group after the PMTU reader accepted index 1 from a two-member group, producing: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: update_or_create_fnhe+0x45/0x15b0 Stop when the indexed path is absent. Groups are dense, so no later index exists in that snapshot. The same real-writer window completed 114,423 PMTU iterations without an oops with this check. A reproducer is available on request. Replacement requires CAP_NET_ADMIN in the network namespace. Where unprivileged user namespaces are permitted, a local user can obtain it in a new user and network namespace. Fixes: 7d3f3b4367f3 ("net: ipv4: Cache pmtu for all packet paths if multipath enabled") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/4fb87ed994dfc067178fc845cdd8bc9b5446b039.1790915964.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 32a8b0adaa18e52aaa0b246b5ffe683075354dbb Author: Michael S. Tsirkin Date: Wed Oct 7 18:42:49 2026 -0400 ipv4: validate checksum_start before completing checksum commit 6785011f8b16abf40b1e9d8b2e332232b3e68822 upstream. If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work. Cc: stable@vger.kernel.org Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr") Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.") Reported-by: Paulos Yibelo Closes: https://lore.kernel.org/netdev/20260922030310.8684-2-habte.yibelo@gmail.com/ Signed-off-by: Michael S. Tsirkin Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/0a012b4923e189c4c593ef4f471e5ff0edbe9030.1791412497.git.mst@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4418070c64a3a9237f4e56490ec8d5371c567fa2 Author: Eric Biggers Date: Sat Oct 10 10:17:20 2026 +0200 crypto: drbg - Fix ineffective sanity check commit 040ad83b0e8aa065fd2fc641cacba8491a8b186d upstream. Fix drbg_healthcheck_sanity() to correctly check the return value of drbg_generate(). drbg_generate() returns 0 on success, or a negative errno value on failure. drbg_healthcheck_sanity() incorrectly assumed that it returned a positive value on success. This didn't make the sanity check fail, but it made it ineffective. Fixes: cde001e4c3c3 ("crypto: rng - RNGs must return 0 in success case") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0ed65708be1282f97eaec5db1e2e18061976aa3b Author: Baochen Qiang Date: Sat Oct 10 01:11:29 2026 -0400 wifi: ath12k: fix reusing m3 memory [ Upstream commit 00575bb44b2c2aa53d0a768de2b80c9c1af0174d ] During firmware recovery or suspend/resume, m3 memory could be reused if the size of the new m3 binary is equal to or less than that of the existing memory. There will be issues for the latter case, since m3_mem->size will be updated with a smaller value and this value is eventually used in the free path, where the original total size should be used instead. To fix it, add a new member in m3_mem_region structure to track the original memory size and use it in free path. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ Backport to 6.12.y: drop the copyright-line hunks, which do not apply to 6.12.y. The code changes are the same as upstream. ] Fixes: 05090ae82f44 ("wifi: ath12k: check M3 buffer size as well whey trying to reuse it") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251029-ath12k-fix-m3-reuse-v1-1-69225bacfc5d@oss.qualcomm.com Signed-off-by: Jeff Johnson Assisted-by: LLM Signed-off-by: Artem Dinaburg Signed-off-by: Sasha Levin commit 9a328ae01489313fe25170449222ded156382fb1 Author: Jiajia Liu Date: Sat Oct 10 04:25:21 2026 +0200 Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING [ Upstream commit 96d006ae6445679436b945593950fd465eba7e76 ] When hci_inquiry_complete_evt is called between le_scan_disable and le_set_scan_enable_complete and no remote name needs to be resolved, the interleaved discovery with SIMULTANEOUS quirk gets stuck in DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry state. No one sets DISCOVERY_STOPPED in this process. Add state check in le_set_scan_enable_complete and change state if the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell Vostro 13. Discovering disabled MGMT Event below is reported when running into the above condition. @ MGMT Command: Start Discovery (0x0023) {0x0001} [hci0] 10885.970873 Address type: 0x07 BR/EDR LE Public LE Random ... < HCI Command: LE Set Extended Scan Enable #38205 [hci0] 10886.131438 Extended scan: Enabled (0x01) Filter duplicates: Enabled (0x01) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Command Complete (0x0e) plen 4 #38206 [hci0] 10886.133295 LE Set Extended Scan Enable (0x08|0x0042) ncmd 2 Status: Success (0x00) @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10886.133414 Address type: 0x07 BR/EDR LE Public LE Random Discovery: Enabled (0x01) < HCI Command: Inquiry (0x01|0x0001) plen 5 #38207 [hci0] 10886.133528 Access code: 0x9e8b33 (General Inquiry) Length: 10.24s (0x08) Num responses: 0 > HCI Event: Command Status (0x0f) plen 4 #38208 [hci0] 10886.141333 Inquiry (0x01|0x0001) ncmd 2 Status: Success (0x00) ... < HCI Command: LE Set Extended Scan Enable #38242 [hci0] 10896.381802 Extended scan: Disabled (0x00) Filter duplicates: Disabled (0x00) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Inquiry Complete (0x01) plen 1 #38243 [hci0] 10896.383419 Status: Success (0x00) > HCI Event: Command Complete (0x0e) plen 4 #38244 [hci0] 10896.394378 LE Set Extended Scan Enable (0x08|0x0042) ncmd 2 Status: Success (0x00) @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497 LE Address: 88:12:AC:92:43:69 RSSI: -101 dBm (0x9b) Flags: 0x00000004 Not Connectable Data length: 8 Company: Xiaomi Inc. (911) Data[0]: 16-bit Service UUIDs (complete): 1 entry Xiaomi Inc. (0xfdaa) @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10896.394506 Address type: 0x07 BR/EDR LE Public LE Random Discovery: Disabled (0x00) Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync") Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz [ Iaroslav: test the quirk with test_bit() on hdev->quirks, as this branch does elsewhere; hci_test_quirk() does not exist here ] Signed-off-by: Iaroslav Voitovych Signed-off-by: Sasha Levin commit fdbd9dc377b62c0a68dccfb11c3a3b44c4be52a7 Author: Liew Rui Yan Date: Fri Oct 9 05:36:50 2026 -0700 mm/damon/core: fix unconditionally skip last region [ Upstream commit b3723b596b548c837a766aae3553c14a7b15af2b ] Once quota set, the charge_{target,addr}_from unconditionally skips and resets at the last region of the tracked target, so the last region can be skipped even when it has not been processed. Example: 1. Target has 2 regions: R1 (0-100 bytes) and R2 (100-200 bytes). 2. Quota is configured to process only 100 bytes per window. 3. Window 1: Processes R1 (0-100). Quota is full. charge_{target, addr}_from is saved at (Target, 100). 4. Window 2: The loop reaches R2. Because R2 is damon_last_region(t), the old code unconditionally returns true, skipping R2 entirely and resetting the charge_{target,addr}_from. Result: R2 is permanently skipped even though it has never been processed. However, it is important to note that this is a very minor issue. This is because it is triggered only when the previous window saved/kept charge_{target,addr}_from, and in the next window, all regions except the last region were skipped by damos_skip_charged_region(). Fix this by only resetting the charge_{target,addr}_from when last region is reached, only skipping when it is applied or cannot split. Link: https://lore.kernel.org/20260908134739.96919-1-sj@kernel.org Fixes: 50585192bc2e ("mm/damon/schemes: skip already charged targets and regions") Signed-off-by: Liew Rui Yan Reviewed-by: SJ Park Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: # v5.16.x Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit e8250813a2fa73d36d92ead260065c8833a4d758 Author: SJ Park Date: Fri Oct 9 05:36:49 2026 -0700 mm/damon/core: do non-safe region walk on kdamond_apply_schemes() [ Upstream commit 1745ccbd2907db2bdaa843e4abccde4fdaccbe5d ] kdamond_apply_schemes() is using damon_for_each_region_safe(), which is safe for deallocation of the region inside the loop. However, the loop internal logic does not deallocate regions. Hence it is only wasting the next pointer. Also, it causes a problem. When an address filter is applied, and there is a region that intersects with the filter, the filter splits the region on the filter boundary. The intention is to let DAMOS apply action to only filtered-in address ranges. However, it is using damon_for_each_region_safe(), which sets the next region before the execution of the iteration. Hence, the region that split and now will be next to the previous region, is simply ignored. As a result, DAMOS applies the action to target regions bit slower than expected, when the address filter is used. Shouldn't be a big problem but definitely better to be fixed. damos_skip_charged_region() was working around the issue using a double pointer hack. Use damon_for_each_region(), which is safe for this use case. And drop the work around in damos_skip_charged_region(). Link: https://lkml.kernel.org/r/20260227170623.95384-3-sj@kernel.org Signed-off-by: SeongJae Park Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit 09fb9d96bb0a2b082b38b5e5ee002d13c95509b3 Author: Chao Yu Date: Fri Oct 9 11:22:20 2026 +0000 f2fs: fix to reset all pinned status during fggc [ Upstream commit 2b8704b6a8b2896ccad1f5941d9a3e2c5031a470 ] Otherwise, the pinned status may affect latter flow of fggc. Cc: stable@kernel.org Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Chao Yu Signed-off-by: Sasha Levin commit 37e273ee2d8f65f4cc0779c39de6a0fbb67be41b Author: Chao Yu Date: Fri Oct 9 11:22:19 2026 +0000 f2fs: fix to shrink gc_lock coverage in f2fs_gc_range() [ Upstream commit 5d49025a4e596c4c9ac0c519ef9f9a2c91396856 ] In f2fs_allocate_pinning_section(), we will hold gc_lock before calling f2fs_gc_range() to migrate section in conventional zone, we may suffer worse case because we may need to traverse and migrate multiple sections if we failed to move blocks in section due to lot of reasons: ENOMEM, fail to migrate block of pinfile, racing on i_gc_rwsem. To avoid hold gc_lock for long time to block checkpoint, let's hold the lock and only try to migrate one section. Cc: stable@kernel.org Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim [ Chao Yu: backport to 6.12.y: - drop file.c changes as f2fs_ioc_reserve_dev_alias() is not present in 6.12 - use f2fs_{down,up}_write(&sbi->gc_lock) as 6.12 lacks lock tracing - use IS_CURSEC() in gc.c as cursec pinning is not present in 6.12 ] Signed-off-by: Chao Yu Signed-off-by: Sasha Levin commit 9fd21fd1d71cbfbd45f7f16205a8f2cfed6da2e9 Author: Chao Yu Date: Fri Oct 9 11:22:18 2026 +0000 f2fs: fix to reclaim space in f2fs_allocate_pinning_section() [ Upstream commit fa487f56efba6344aef67d871688f0908fe08af3 ] It needs to trigger checkpoint to free space reclaimed by f2fs_gc_range(), otherwise, fallocate() on pinfile will fail easily even there is slash space in conventional zone. [Testcase] nullblk_create.sh 512 2 1024 1024 mkfs.f2fs /dev/nullb0 -f -m mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile mkdir /mnt/f2fs/dir/ for((i=0;i<3934;i++)) do { dd if=/dev/zero of=/mnt/f2fs/dir/$i bs=1M count=1;} done sync for((i=0;i<3934;i+=2)) do { rm /mnt/f2fs/dir/$i;} done for((i=0;i<1950;i++)) do { rm /mnt/f2fs/dir/$i;} done sync f2fs_io fallocate 0 0 $((1024*1024*1024)) /mnt/f2fs/pinfile sync stat /mnt/f2fs/pinfile f2fs_io fiemap 0 $((1024*1024*1024)) /mnt/f2fs/pinfile [Before] fallocate failed: Resource temporarily unavailable File: /mnt/f2fs/pinfile Size: 109051904 Blocks: 213208 IO Block: 4096 regular file Device: 250,0 Inode: 4 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-08-12 20:04:02.264000000 +0800 Modify: 2026-08-12 20:04:26.784000000 +0800 Change: 2026-08-12 20:04:26.784000000 +0800 Birth: - root@localhost:~# root@localhost:~# root@localhost:~# root@localhost:~# f2fs_io fiemap 0 $((1024*1024*1024)) /mnt/f2fs/pinfile Fiemap: offset = 0 len = 1073741824 logical addr. physical addr. length flags 0 0000000000000000 0000000002e00000 0000000000200000 00001000 1 0000000000200000 000000002dc00000 0000000000400000 00001000 2 0000000000600000 000000002e400000 0000000000600000 00001000 3 0000000000c00000 000000007a400000 0000000005c00000 00001001 [After] File: /mnt/f2fs/pinfile Size: 1073741824 Blocks: 2099216 IO Block: 4096 regular file Device: 250,0 Inode: 4 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-08-12 19:47:49.428000000 +0800 Modify: 2026-08-12 19:49:06.808000000 +0800 Change: 2026-08-12 19:49:06.808000000 +0800 Birth: - Fiemap: offset = 0 len = 1073741824 logical addr. physical addr. length flags 0 0000000000000000 0000000002e00000 0000000000200000 00001000 1 0000000000200000 000000003aa00000 0000000000400000 00001000 2 0000000000600000 000000003b400000 0000000000200000 00001000 3 0000000000800000 000000007a200000 0000000005e00000 00001000 4 0000000006600000 0000000002800000 0000000000200000 00001000 5 0000000006800000 0000000003200000 0000000000400000 00001000 6 0000000006c00000 0000000003000000 0000000000200000 00001000 7 0000000006e00000 0000000003600000 0000000037200000 00001000 8 000000003e000000 000000003b200000 0000000000200000 00001000 9 000000003e200000 000000003a800000 0000000000200000 00001000 10 000000003e400000 000000003ae00000 0000000000400000 00001000 11 000000003e800000 000000003b600000 0000000001800000 00001001 Cc: stable@kernel.org Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim [ Chao Yu: backport to 6.12.y: - retain existing f2fs_up_write(&sbi->gc_lock) as 6.12 lacks lock tracing ] Signed-off-by: Chao Yu Signed-off-by: Sasha Levin commit d2dc70befdd29054904fb1ebdf86d1a7a41a86b9 Author: Remy D. Farley Date: Sat Oct 10 06:51:16 2026 +0300 doc/netlink: netlink-raw: Add max check commit bf5a54bc0e3d8962474fcd611f1266eba036232f upstream. Add definitions for max check and len-or-limit type, the same as in other specifications. Suggested-by: Donald Hunter Reviewed-by: Donald Hunter Signed-off-by: Remy D. Farley Link: https://patch.msgid.link/20260303195638.381642-2-one-d-wide@protonmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Anton Danilov Signed-off-by: Sasha Levin commit f4697cbe3fab74270020813121874aaf9f30fddb Author: Jakub Kicinski Date: Sat Oct 10 06:51:15 2026 +0300 tools: ynl: add scope qualifier for definitions commit fbf5df34a4dbcd09d433dd4f0916bf9b2ddb16de upstream. Using definitions in kernel policies is awkward right now. On one hand we want defines for max values and such. On the other we don't have a way of adding kernel-only defines. Adding unnecessary defines to uAPI is a bad idea, we won't be able to delete them. And when it comes to policy user space should just query it via the policy dump, not use hard coded defines. Add a "scope" property to definitions, which will let us tell the codegen that a definition is for kernel use only. Support following values: - uapi: render into the uAPI header (default, today's behavior) - kernel: render to kernel header only - user: same as kernel but for the user-side generated header Definitions may have a header property (definition is "external", provided by existing header). Extend the scope to headers, too. If definition has both scope and header properties we will only generate the includes in the right scope. Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-8-kuba@kernel.org Signed-off-by: Paolo Abeni [ Anton: the generator is tools/net/ynl/ynl-gen-c.py in 6.12.y and its context differs, the hunks were applied by hand without changes. 6.12.y lacks commit 3ff5258b9781 ("tools: ynl-gen: allow overriding name-prefix for constants"), so render_uapi() ignores name-prefix of constants while render_scoped_consts() honours it, as upstream does. No spec in 6.12.y has a constant with name-prefix. ] Assisted-by: LLM Signed-off-by: Anton Danilov Signed-off-by: Sasha Levin commit 83702e5a759f133bdf7c333647badd0edba0a40b Author: Jakub Kicinski Date: Sat Oct 10 06:51:14 2026 +0300 tools: ynl-gen: support limits using definitions commit fa796178e5eb0078a9a6c36f60fd6494cfc3f81d upstream. Support using defines / constants in integer checks. Carolina will need this for rate API extensions. Reported-by: Carolina Jubran Link: https://lore.kernel.org/1e886aaf-e1eb-4f1a-b7ef-f63b350a3320@nvidia.com Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20250203215510.1288728-2-kuba@kernel.org Signed-off-by: Paolo Abeni [ Anton: the generator is tools/net/ynl/ynl-gen-c.py in 6.12.y. ] Assisted-by: LLM Signed-off-by: Anton Danilov Signed-off-by: Sasha Levin commit 30e86b2840e98f6d286c484825fcf53fe3b6ee59 Author: Jakub Kicinski Date: Sat Oct 10 06:51:13 2026 +0300 tools: ynl-gen: use names of constants in generated limits commit bcbbfaa2612d7d0e9c3eafade5f6e93c3672f34f upstream. YNL specs can use string expressions for limits, like s32-min or u16-max. We convert all of those into their numeric values when generating the code, which isn't always helpful. Try to retain the string representations in the output. Any sort of calculations still need the integers. Signed-off-by: Jakub Kicinski Reviewed-by: Joe Damato Link: https://patch.msgid.link/20241010151248.2049755-1-kuba@kernel.org [pabeni@redhat.com: regenerated netdev-genl-gen.c] Signed-off-by: Paolo Abeni [ Anton: 6.12.y has the older TypeBinary._attr_policy(), switch its get_limit() calls to get_limit_str() there. Drop the netdev_a_napi_defer_hard_irqs_range hunk from netdev-genl-gen.c, that range does not exist in 6.12.y. The file now matches what ynl-gen-c.py generates. ] Assisted-by: LLM Signed-off-by: Anton Danilov Signed-off-by: Sasha Levin commit f64b5563f628bbc8f2bc9e9213c9e98327676bf4 Author: Matti Vaittinen Date: Mon Aug 10 10:53:35 2026 +0300 iio: light: rohm-bu27034: Fix error return [ Upstream commit 4e5b0b7c5d95814b6d76911a91572a0691925ca7 ] When BU27034 fails to read gain value at integration-time setting, it returns 0. This leaves caller unaware of the fact that setting the integration time failed. Fix this by returning the relevant error instead of zero. Fixes: 439c2cef8157 ("iio: bu27034: simplify using guard(mutex)") Signed-off-by: Matti Vaittinen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 050482f958521d80603e88d5c3a59872528ec13c Author: Matti Vaittinen Date: Wed Oct 7 05:02:25 2026 -0400 iio: light: rohm-bu27034: Fix infinite delay on error [ Upstream commit 8065a6c02f629187131f3136bedb26f9080e3cca ] When reading an integration-time fails, the code will use error code to compute the sleep time. Fix this by using the smallest integration time as a default if reading fails. Fixes: e52afbd61039 ("iio: light: ROHM BU27034 Ambient Light Sensor") Suggested-by: Jonathan Cameron Signed-off-by: Matti Vaittinen Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7805492fc948e8d14a40d2045d86b0023f52786a Author: Matti Vaittinen Date: Wed Oct 7 05:02:24 2026 -0400 iio: bu27034: simplify using guard(mutex) [ Upstream commit 439c2cef8157bd3856200effdf4bb4ce3ff8e774 ] The BU27034 uses mutex for protecting the gain / time / scale changes. The clean-up for a few of the functions can be slightly simplified by removing the goto-based error handling/unlocking and by utilizing the guard(mutex) scoped mutex handling instead. Simplify driver by using the scoped mutexes. Signed-off-by: Matti Vaittinen Reviewed-by: Javier Carrasco Link: https://patch.msgid.link/4e65a4725c211b166906f70fdb5ba90f2af0f570.1732193263.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron Stable-dep-of: 8065a6c02f62 ("iio: light: rohm-bu27034: Fix infinite delay on error") Signed-off-by: Sasha Levin commit 581a7a6a02fd1917c5aa13164b29f3ffb221afcb Author: Pengpeng Hou Date: Wed Oct 7 03:46:11 2026 -0400 iio: cdc: ad7150: fix OF matching and publish module aliases [ Upstream commit 52da294027f53e7084c18dd4b4f73354a40382f3 ] The OF match entries use positional initializers, which initialize the name field rather than compatible. Consequently the advertised AD7150, AD7151 and AD7156 compatible strings do not describe OF compatible matches. The table is also not exported for module alias generation. Use designated compatible initializers and publish the OF table. Keep the existing I2C ID table and its device-variant selection unchanged. The issue was found by our static-analysis tool. Fixes: 89f2d5b080bc ("staging:iio:cdc:ad7150: Add of_match_table") Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Jonathan Cameron [ sashal: Retained the existing `{}` table terminator formatting instead of upstream’s `{ }`. ] Signed-off-by: Sasha Levin commit 4812d79e62c8fdf6dea1dbf46b14abe7069674f7 Author: Michael Hennerich Date: Wed Oct 7 04:46:25 2026 -0400 iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs [ Upstream commit 0d0ffbcc92e30a8d656ad76a6e278fa3400fed85 ] iio_dmaengine_buffer_submit_block() counts scatterlist entries with sg_nents_for_len(), which walks the CPU-side lengths (sg->length), but then consumes the DMA-side fields (sg_dma_address()/sg_dma_len()). After dma_map_sgtable() the two views may differ: an IOMMU can coalesce the mapping so that only the first sgt->nents entries carry valid DMA addresses, with nents < orig_nents. On x86 with an IOMMU enabled, a DMABUF block backed by two 1 MiB system-heap chunks maps to a single 2 MiB IOVA range. The CPU-side count is 2, so the loop reads one entry past the mapped set and emits a garbage vec ({addr = ~0, len = 0}). The DMA engine driver rejects the vec array (prep returns NULL), the fence is signalled with -ENOMEM, which a userspace poller cannot observe, and the block is left in ACTIVE state so every further enqueue of it fails with -EBUSY. The visible symptom is a stream of zero-filled blocks followed by a wedged buffer. Platforms without an IOMMU never hit this because nents == orig_nents. Size the vec array with sgt->nents, i.e. the DMA-mapped view, and stop the fill loop once bytes_used is covered - which is allowed to be smaller than the block size - passing the number of vecs actually filled to dmaengine_prep_peripheral_dma_vec(). One vec per mapped entry is enough since coalescing can only ever reduce the number of entries. A single mapped entry longer than the device's maximum segment size would need more than one, but the DMA API already assumes no single segment exceeds it [1], and splitting a vec down to the hardware descriptor size is the DMA engine driver's job - which both current .device_prep_peripheral_dma_vec() implementations do. [1]: commit ab2cbeb0ed30 ("iommu/dma: Handle SG length overflow better") Assisted-by: Claude:claude-fable-5 Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron [ sashal: adjusted context due to missing cyclic DMA flag handling ] Signed-off-by: Sasha Levin commit 4e624fc043719bbe8ec329558cdd9102b4dc9429 Author: Paulo Alcantara Date: Wed Oct 7 03:18:33 2026 -0400 smb: client: only require read lease for size-extending preallocate [ Upstream commit b5d59e7270d078ab28a9c4b4d11dc3eb24671988 ] smb3_simple_falloc() refuses any fallocate that clears FALLOC_FL_KEEP_SIZE with -EOPNOTSUPP whenever the inode is not read caching: /* if file not oplocked can't be sure whether asking to extend size */ if (!CIFS_CACHE_READ(cifsi)) if (!keep_size) { ... return rc; } As with smb3_zero_range(), the read lease is only needed to trust the cached size when deciding whether the request extends the file. When it is not held, the size can instead be fetched from the server, which is authoritative, rather than refusing the request outright: after flushing, query the server's end of file and take the larger of it and the cached size for the interior-vs-extend decision. The larger of the two is used because the server's end of file reflects another client's growth while the cached size reflects this client's own writes that may not have reached the server yet; using the server size alone would wrongly treat an interior request as extending when a range flush left an extending write unwritten. smb3_simple_fallocate_range(), which performs the actual interior emulation, decided whether the range already lies past EOF from its own i_size_read(inode) rather than the old_eof computed above. In the leaseless case, that is exactly the stale, undershooting size this patch works around: a genuinely interior range can read as past EOF by that stale count, which skips the FSCTL_QUERY_ALLOCATED_RANGES check entirely and overwrites already-allocated server data with zeroes instead of only filling the holes. Pass old_eof into smb3_simple_fallocate_range() and use it for that comparison instead of re-deriving a second, inconsistent one. Rejecting interior requests is observed as generic/363 randomly failing against Windows Server with do_preallocate: fallocate: Operation not supported fsx issues an interior, non-KEEP_SIZE preallocate while the inode is transiently not read caching: the server had just downgraded the file's lease from RWH to RH after breaking the write caching, and the ensuing handle reopen/revalidation left CIFS_CACHE_READ momentarily clear. The range sat within the server's end of file, so no extend was needed, yet it was refused and fsx aborted. This keeps the emulation correct even when a genuine lease break from another client leaves the inode without read caching -- the case the -EOPNOTSUPP guard turned into a hard failure. The extra flush and round trip only happen when both keep_size is false and no read lease is held; every other case is unchanged. Fixes: 9ccf3216238c ("Add support for original fallocate") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced unavailable query_server_eof() with an equivalent SMB2_query_info() call. ] Signed-off-by: Sasha Levin commit 30d27899cbba5b080954b5d3741bd535806c3101 Author: Fabrice Gasnier Date: Wed Oct 7 03:18:24 2026 -0400 iio: adc: stm32-adc: fix possible division by zero in processed channel [ Upstream commit c5de6a6f855fdcf1e0ea549fb227a316db51c405 ] In case the conversion has failed or returned zero, processing *val can lead to a division by zero. Need to check for errors, or converted value is zero, before processing the data. In case the converted value is zero, e.g. the Vrefint channel, this should be considered as invalid in all cases. Fixes: 0e346b2cfa85 ("iio: adc: stm32-adc: add vrefint calibration support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260911161555.244F31F000FF@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Fabrice Gasnier Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron [ sashal: Changed iio_device_release_direct() to iio_device_release_direct_mode(). ] Signed-off-by: Sasha Levin commit 773376ef7dd85a567e928693556dc33425faa115 Author: Vladyslav Ivashchenko Date: Wed Oct 7 03:13:29 2026 -0400 iio: adc: axp288: Add TS bias override for Haier HV103H [ Upstream commit 0f300db7b7315b2c7ea0e2d4437b88de162d191f ] The Haier HV103H firmware configures the AXP288 TS pin bias current to 60 uA. This causes the battery temperature reading to cross the charging temperature threshold under load, incorrectly stopping battery charging. Setting the TS bias current to 80 uA fixes the temperature measurement and prevents charging from being incorrectly disabled. Add a DMI quirk to use the 80 uA TS bias current on the Haier HV103H. Fixes: 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling") Fixes: 048058399f19 ("iio: adc: axp288: Override TS pin bias current for some models") # Add necessary infrastructure Signed-off-by: Vladyslav Ivashchenko Reviewed-by: Hans de Goede Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron [ sashal: Adjusted context to preserve the existing `{}` DMI table terminator instead of `{ }`. ] Signed-off-by: Sasha Levin commit ac816a93f07b2039983bad4940d03240e8ec3b21 Author: Cong Nguyen Date: Wed Oct 7 03:03:56 2026 -0400 iio: adc: max1363: sign-extend bipolar differential channel reads [ Upstream commit 91908c0a78baddc8572aa3ab69e62ee2eb496ba4 ] MAX1363 differential channels are bipolar, but max1363_read_single_chan() masks the raw value to the ADC resolution without sign-extending it. Negative differential readings are therefore reported to userspace as large positive values (e.g. -1 as 4095 on a 12-bit part). Sign-extend the masked value from the resolution bit for differential channels. Single-ended channels are unipolar and are left unchanged. Fixes: d1325cf45077 ("Staging: IIO: max1363 ADC driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron [ sashal: Adjusted indentation to fit the existing iio_device_claim_direct_scoped() block. ] Signed-off-by: Sasha Levin commit d0dfe5ea29e2eb31c7f7ffbc2f8d897b3bf6b4f9 Author: Pengpeng Hou Date: Wed Oct 7 02:22:45 2026 -0400 iio: adc: aspeed: propagate reset deassert errors [ Upstream commit 95e4eb426b4bd666fa2f37886c0ddf74a0cc6167 ] aspeed_adc_probe() continues to register ADC resources after deasserting the shared reset, even if the reset controller reports a failure. A failed deassertion leaves the hardware unavailable, so stop probing before installing the cleanup action and enabling the ADC. Fixes: edf7550a1f93 ("iio: adc: aspeed: Deassert reset in probe") Signed-off-by: Pengpeng Hou Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3cada8f339f578c6f0dd2290a00a38cefd4c2655 Author: Krzysztof Kozlowski Date: Wed Oct 7 02:22:44 2026 -0400 iio: adc: aspeed: Simplify with dev_err_probe [ Upstream commit dcc3ac29f46fff6775c0a945afc68fd9dece6d34 ] Use dev_err_probe() to make error code handling simpler and handle deferred probe nicely (avoid spamming logs). Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Cameron Stable-dep-of: 95e4eb426b4b ("iio: adc: aspeed: propagate reset deassert errors") Signed-off-by: Sasha Levin commit 84500ae0d976995a6870cb1dca2d124b6b2d6e5a Author: Fan Wu Date: Wed Oct 7 02:10:01 2026 -0400 iio: adc: ad_sigma_delta: fix use-after-free on unbind [ Upstream commit 9ee8306121495d2a25aa5d1bfd519f2748786b83 ] ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with devm_krealloc() at runtime, so its devres entry sits after all probe-time entries of the driver. devm resources are released in reverse allocation order, which means unbind frees samples_buf before iio_device_unregister() disables the buffers and detaches the trigger pollfunc. The data ready IRQ is still enabled at that point, so ad_sd_trigger_handler() can still run and memcpy() incoming samples into the freed samples_buf. Fix this by preallocating the buffer in devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and the IRQ are set up, so it is freed only after iio_device_unregister() has drained the trigger handler via free_irq(). Size it for the worst case of all sequencer slots being active; ad_sd_validate_scan_mask() already caps the number of active channels at num_slots. This issue was found by an in-house static analysis tool. Fixes: 8bea9af887de ("iio: adc: ad_sigma_delta: Add sequencer support") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron [ sashal: Made the allocation unconditional because the offload conditional is absent. ] Signed-off-by: Sasha Levin commit e3bc345d08639e62b629e0ec0799f7fb45e21372 Author: Matti Vaittinen Date: Wed Oct 7 01:44:15 2026 -0400 iio: accel: kionix-kx022a: Prevent memory leak and fix state [ Upstream commit e65e128b51a37dd1a9056ac3d1705d805a5c8bb0 ] The driver allocates memory for samples at buffer enable path. If regmap operation fails in the kx022a_fifo_enable() at the buffer enable path, the allocated memory is never freed. Furthermore, the state information and previous hardware configuration(s) aren't undone, potentially leaving WMI interrupts and buffers enabled, or driver state flags wrong. Free the memory and revert the hardware configuration and state flags on error path. Fixes: e7123a4dfcd7 ("iio: accel: kionix-kx022a: Refactor driver and add chip_info structure") Signed-off-by: Matti Vaittinen Reviewed-by: Mehdi Djait Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1f3407ab65ce604c10a238a8310b371460ae3c83 Author: Matti Vaittinen Date: Wed Oct 7 01:44:14 2026 -0400 iio: accel: kx022a: Use cleanup.h helpers [ Upstream commit 725521e1f485d4687790f2e459271f1ad6af64d5 ] A few functions in KX022A need to use mutex for protecting the enabling/disabling of the measurement while configurations are being made. Some of the functions can be slightly simplified by using the __cleanup based scoped mutexes, which allows dropping the goto based unlocking at error path. Simplify error paths using guard(mutex). Signed-off-by: Matti Vaittinen Link: https://patch.msgid.link/4785f841ad5f131356ba78b4f3c76f676d86a2e8.1732783834.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron Stable-dep-of: e65e128b51a3 ("iio: accel: kionix-kx022a: Prevent memory leak and fix state") Signed-off-by: Sasha Levin commit 93c1b247224a32f546b616a8fe87b9bab20f0a7f Author: Felix Fietkau Date: Tue Oct 6 18:33:38 2026 -0400 wifi: mac80211: set info->band for 802.3 encap offload frames [ Upstream commit 4febc02cd02f021f2b6d0768332be643ef14a12d ] Unlike the 802.11 TX paths, ieee80211_8023_xmit() does not set info->band from the channel context on non-MLD interfaces. It stays at 0, so ieee80211_get_tx_rates() uses the wrong band for these frames. Set it the same way as ieee80211_build_hdr(): drop the frame if there is no channel context, and leave the band at 0 on MLD interfaces. Reported-by: Andrea Pesaresi Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260926120216.4054712-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 99cf565c1198abb7209845f4e0dfc6356d1060ad Author: Tamizh Chelvam Raja Date: Tue Oct 6 18:33:37 2026 -0400 wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit() [ Upstream commit 303f11fda2fa4c6f7aa86b8fa54aaee5e1ef181b ] Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: 4febc02cd02f ("wifi: mac80211: set info->band for 802.3 encap offload frames") Signed-off-by: Sasha Levin commit 74836ae4785b9754bb36d0b18fcc1dec4e5e98d2 Author: Sean Christopherson Date: Tue Oct 6 13:56:51 2026 -0400 KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted [ Upstream commit 9e06bbb9ade7cdf28d4a3b5b14e5812881c8df85 ] Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM needs to merge msprm01 with msrpm12. Don't bother tracking the virtual address of the bitmap that's being used, as __va() is cheap on x86, and caching the virtual address would introduce yet another source of potentially stale information. Fixes: b2ac58f90540 ("KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson Message-ID: <20260826195833.844526-1-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Adapted VMCB access to use to_svm(vcpu) with the existing struct kvm_vcpu parameter. ] Signed-off-by: Sasha Levin commit a79b45c628008c90da5eccec3407e927f4655e67 Author: Dipayaan Roy Date: Wed Apr 29 20:57:54 2026 -0700 net: mana: remove double CQ cleanup in mana_create_rxq error path [ Upstream commit 3985c9a56da49af8b2e45cb1fa55c03c89b1d471 ] In mana_create_rxq(), the error cleanup path calls mana_destroy_rxq() followed by mana_deinit_cq(). This is incorrect for two reasons: 1. mana_destroy_rxq() already calls mana_deinit_cq() internally, so the CQ's GDMA queue is destroyed twice. 2. mana_destroy_rxq() frees the rxq via kfree(rxq) before returning. The subsequent mana_deinit_cq(apc, cq) then operates on freed memory since cq points to &rxq->rx_cq, which is embedded in the already-freed rxq structure — a use-after-free. Remove the redundant mana_deinit_cq() call from the error path since mana_destroy_rxq() already handles CQ cleanup. mana_deinit_cq() is itself safe for an uninitialized CQ as it checks for a NULL gdma_cq before proceeding. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Reviewed-by: Aditya Garg Link: https://patch.msgid.link/20260430035935.1859220-4-dipayanroy@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 797f931a28e4eef713c074b0440e032bfe88af4f Author: Dipayaan Roy Date: Wed Apr 29 20:57:53 2026 -0700 net: mana: Skip WQ object destruction for uninitialized RXQ [ Upstream commit 2a1c691182823a5c149d502ac153e249ee697b4a ] In mana_destroy_rxq(), mana_destroy_wq_obj() is called unconditionally even when the WQ object was never created (rxobj is still INVALID_MANA_HANDLE). When mana_create_rxq() fails before mana_create_wq_obj() succeeds, the error path calls mana_destroy_rxq() which sends a bogus destroy command to the hardware: mana 7870:00:00.0: HWC: Failed hw_channel req: 0x1d mana 7870:00:00.0: Failed to send mana message: -71, 0x1d mana 7870:00:00.0 eth7: Failed to destroy WQ object: -71 Guard mana_destroy_wq_obj() with an INVALID_MANA_HANDLE check so that mana_destroy_rxq() is safe to call at any stage of RXQ initialization. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20260430035935.1859220-3-dipayanroy@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 394f33347a9dcd3276425255a37b4d73aa64ef2b Author: Dipayaan Roy Date: Wed Apr 29 20:57:52 2026 -0700 net: mana: check xdp_rxq registration before unreg in mana_destroy_rxq() [ Upstream commit e9e334f8063a991b4f648b8dbb8dac44cf810540 ] When mana_create_rxq() fails at mana_create_wq_obj() or any step before xdp_rxq_info_reg() is called, the error path jumps to `out:` which calls mana_destroy_rxq(). mana_destroy_rxq() unconditionally calls xdp_rxq_info_unreg() on xilinx xdp_rxq that was never registered, triggering a WARN_ON in net/core/xdp.c: mana 7870:00:00.0: HWC: Failed hw_channel req: 0xc000009a mana 7870:00:00.0 eth7: Failed to create RXQ: err = -71 Driver BUG WARNING: CPU: 442 PID: 491615 at ../net/core/xdp.c:150 xdp_rxq_info_unreg+0x44/0x70 Modules linked in: tcp_bbr xsk_diag udp_diag raw_diag unix_diag af_packet_diag netlink_diag nf_tables nfnetlink tcp_diag inet_diag binfmt_misc rpcsec_gss_krb5 nfsv3 nfs_acl auth_rpcgss nfsv4 dns_resolver nfs lockd ext4 grace crc16 iscsi_tcp mbcache fscache libiscsi_tcp jbd2 netfs rpcrdma af_packet sunrpc rdma_ucm ib_iser rdma_cm iw_cm iscsi_ibft ib_cm iscsi_boot_sysfs libiscsi rfkill scsi_transport_iscsi mana_ib ib_uverbs ib_core mana hyperv_drm(X) drm_shmem_helper intel_rapl_msr drm_kms_helper intel_rapl_common syscopyarea nls_iso8859_1 sysfillrect intel_uncore_frequency_common nls_cp437 vfat fat nfit sysimgblt libnvdimm hv_netvsc(X) hv_utils(X) fb_sys_fops hv_balloon(X) joydev fuse drm dm_mod configfs ip_tables x_tables xfs libcrc32c sd_mod nvme nvme_core nvme_common t10_pi crc64_rocksoft_generic crc64_rocksoft crc64 hid_generic serio_raw pci_hyperv(X) hv_storvsc(X) scsi_transport_fc hyperv_keyboard(X) hid_hyperv(X) pci_hyperv_intf(X) crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd hv_vmbus(X) softdog sg scsi_mod efivarfs Supported: Yes, External CPU: 442 PID: 491615 Comm: ethtool Kdump: loaded Tainted: G X 5.14.21-150500.55.136-default #1 SLE15-SP5 a627be1b53abbfd64ad16b2685e4308c52847f42 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 07/25/2025 RIP: 0010:xdp_rxq_info_unreg+0x44/0x70 Code: e8 91 fe ff ff c7 43 0c 02 00 00 00 48 c7 03 00 00 00 00 5b c3 cc cc cc cc e9 58 3a 1c 00 48 c7 c7 f6 5f 19 97 e8 5c a4 7e ff <0f> 0b 83 7b 0c 01 74 ca 48 c7 c7 d9 5f 19 97 e8 48 a4 7e ff 0f 0b RSP: 0018:ff3df6c8f7207818 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ff30d89f94808a80 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000002 RDI: ff30d94bdcca2908 RBP: 0000000000080000 R08: ffffffff98ed11a0 R09: ff3df6c8f72077a0 R10: dead000000000100 R11: 000000000000000a R12: 0000000000000000 R13: 0000000000002000 R14: 0000000000040000 R15: ff30d89f94800000 FS: 00007fe6d8432b80(0000) GS:ff30d94bdcc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe6d81a89b1 CR3: 00000b3b6d578001 CR4: 0000000000371ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: mana_destroy_rxq+0x5b/0x2f0 [mana 267acf7006bcb696095bba4d810643d1db3b9e94] mana_create_rxq.isra.55+0x3db/0x720 [mana 267acf7006bcb696095bba4d810643d1db3b9e94] ? simple_lookup+0x36/0x50 ? current_time+0x42/0x80 ? __d_free_external+0x30/0x30 mana_alloc_queues+0x32a/0x470 [mana 267acf7006bcb696095bba4d810643d1db3b9e94] ? _raw_spin_unlock+0xa/0x30 ? d_instantiate.part.29+0x2e/0x40 ? _raw_spin_unlock+0xa/0x30 ? debugfs_create_dir+0xe4/0x140 mana_attach+0x5c/0xf0 [mana 267acf7006bcb696095bba4d810643d1db3b9e94] mana_set_ringparam+0xd5/0x1a0 [mana 267acf7006bcb696095bba4d810643d1db3b9e94] ethnl_set_rings+0x292/0x320 genl_family_rcv_msg_doit.isra.15+0x11b/0x150 genl_rcv_msg+0xe3/0x1e0 ? rings_prepare_data+0x80/0x80 ? genl_family_rcv_msg_doit.isra.15+0x150/0x150 netlink_rcv_skb+0x50/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1b6/0x280 netlink_sendmsg+0x365/0x4d0 sock_sendmsg+0x5f/0x70 __sys_sendto+0x112/0x140 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x80 ? handle_mm_fault+0xd7/0x290 ? do_user_addr_fault+0x2d8/0x740 ? exc_page_fault+0x67/0x150 entry_SYSCALL_64_after_hwframe+0x6b/0xd5 RIP: 0033:0x7fe6d8122f06 Code: 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 f3 c3 41 57 41 56 4d 89 c7 41 55 41 54 41 RSP: 002b:00007fff2b66b068 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055771123d2a0 RCX: 00007fe6d8122f06 RDX: 0000000000000034 RSI: 000055771123d3b0 RDI: 0000000000000003 RBP: 00007fff2b66b100 R08: 00007fe6d8203360 R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000246 R12: 000055771123d350 R13: 000055771123d340 R14: 0000000000000000 R15: 00007fff2b66b2b0 Guard the xdp_rxq_info_unreg() call with xdp_rxq_info_is_reg() so that mana_destroy_rxq() is safe to call regardless of how far initialization progressed. Fixes: ed5356b53f07 ("net: mana: Add XDP support") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20260430035935.1859220-2-dipayanroy@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d215d09606b0fcd18ad1eb532995782a21cea49d Author: Jerome Tollet Date: Mon Aug 24 16:16:45 2026 +0200 net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry [ Upstream commit 63811edf512584c946e5e96b100e9e280703bbb5 ] With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actual_wq_head is not advanced and a later NAPI poll retries the same WQE. mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On retry it can therefore call xsk_buff_free() again through stale pointers after the frames have returned to the XSK pool and been reallocated. Set all skip_release_bitmap bits in the common error path of mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path. Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings. Fixes: 4c2a13236807 ("net/mlx5e: RX, Defer page release in striding rq for better recycling") Cc: stable@vger.kernel.org Signed-off-by: Jerome Tollet Reviewed-by: Dragos Tatulea Link: https://patch.msgid.link/20260824141645.23700-3-jtollet@cisco.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 34d1db2b18e1c1d189e34dd51923e031815f88e3 Author: Jerome Tollet Date: Mon Aug 24 16:16:44 2026 +0200 net/mlx5e: Prevent stale XSK buffer release on refill retry [ Upstream commit e01620844c5c88b6fcf819d171df8e3976a0e76f ] When an XDP redirect to an AF_XDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer. The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice. Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers. The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events, with no ownership or data errors. Fixes: 3f93f82988bc ("net/mlx5e: RX, Defer page release in legacy rq for better recycling") Cc: stable@vger.kernel.org Suggested-by: Daniel Borkmann Reviewed-by: Dragos Tatulea Signed-off-by: Jerome Tollet Link: https://patch.msgid.link/20260824141645.23700-2-jtollet@cisco.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21f51434c47d8628b62275ae6c6ad6b573abcd02 Author: Matthew Wilcox (Oracle) Date: Tue Jun 23 20:28:48 2026 +0100 fs: Free any excess xarray nodes in clear_inode() [ Upstream commit ee3f011250104129893d8e9599147e457d4d7280 ] For many years we've had a hard to hit leak of xarray nodes. Hugh documented it well in commit 786b31121a2c. Recently people and syzbot have found ways to force it to happen with madvise. Rather than fix the leaks where they happen, just call xa_destroy() which has the side-effect of cycling the i_pages lock. Cc: Rik van Riel Cc: Zi Yan Cc: Jinjiang Tu Cc: Dave Jones Link: https://lore.kernel.org/all/20260121062243.1893129-1-tujinjiang@huawei.com/ Signed-off-by: Matthew Wilcox (Oracle) Link: https://patch.msgid.link/20260623192850.1595958-1-willy@infradead.org Reviewed-by: Rik van Riel Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit d31f655e44631891788ca67018ec5e1ed1c7de86 Author: Zhiling Zou Date: Tue Oct 6 17:32:01 2026 -0400 wifi: mac80211: count only matching reservations in reserved switch [ Upstream commit 437f3727b4fd715266c296435c116288f82666fd ] ieee80211_vif_use_reserved_switch() validates a replacement by counting assigned links on ctx->replace_ctx and treating reservations too broadly. A link can still be assigned to the old channel context while holding a reservation that belongs to a different replacement operation. That can make the current replacement appear complete too early. If another link finalizes first, the function can free the WILL_BE_REPLACED chanctx while the unmatched link and driver still use it, leading to a use-after-free in later beacon generation. Require an in-place reservation to point at the current replacement context, and require the reserved and assigned contexts to be the matching replacement pair, before counting or moving the link. Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/4b6c4b8648ab1920c38a40be32c0b1a2797b4ac6.1785726007.git.zhilinz@nebusec.ai Signed-off-by: Johannes Berg [ sashal: adapted iter.link-based channel-context iteration to direct link-list traversal. ] Signed-off-by: Sasha Levin commit 6d1a984afc3ca477dab3e51ec806671d443ad524 Author: Johan Hovold Date: Thu Sep 10 14:51:14 2026 +0200 tty: port: fix tty_port_tty_vhangup() race [ Upstream commit b48820de8c1a596c5b99775524dfce73c6576c5d ] Drivers rely on tty_port_tty_vhangup() to synchronously hang up their ports before tearing down resources as part of deregistration (e.g. on physical disconnect). If tty_port_tty_vhangup() races with another hangup it may however return before the port has been shut down. This is in turn can lead to use-after-free and NULL-pointer dereferences in racing ioctls (including a synchronous hangup) and in processing of racing asynchronous hangups (carrier loss). Add the missing serialisation to tty_port_tty_vhangup() and tty_port_hangup() so that the former does not return until the port has been shut down also when there is a racing hangup. Note that serial core does not use tty_port_hangup(), but it already holds the port mutex when clearing port->tty and shutting down the port in uart_hangup(). Fixes: 7ca0ff9ab321 ("tty: Add a full port_close function") Cc: stable@kernel.org # 2.6.32: 2b5eac0f8c6e: tty: introduce and use tty_port_tty_vhangup() helper Cc: stable@kernel.org # 2.6.32 Reported-by: syzbot+5fabc1ae99ff40690d84@syzkaller.appspotmail.com Link: https://lore.kernel.org/6a944641.4d659fcc.734b4.003c.GAE@google.com Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910125114.640880-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2956aca14dd2977cd08bd2ccafae3beb8b84b268 Author: Eric Dumazet Date: Wed Oct 7 07:17:47 2026 +0200 bnxt_en: fix DMA mapping length for padded small packets [ Upstream commit a51d233ccd4889aadb71dace863525cc2b00271e ] Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB page (within 'pad' bytes of the next page), the hardware DMA read overruns into the unmapped adjacent page, triggering an IOMMU fault. This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") because reserving extra VLAN headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data offsets and potentially causing small frames to land right against page boundaries. Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled, because padding might linearize the skb. This ensures skb->len and skb_headlen(skb) reflect the padded size so that dma_map_single() maps the full buffer and the descriptor length is consistent. This also removes the temporary 'pad' variable and masking logic. The padding is done after the SW USO branch, otherwise bnxt_sw_udp_gso_xmit() would account the padding as UDP payload and send it in extra segments. Note that SW USO segments are still not padded: with IPv4, a segment carrying less than 10 bytes of UDP payload (small gso_size, or a short last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE. This is a separate issue, left for a followup patch. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Cc: stable@vger.kernel.org Reported-by: Stefan Fleischmann Closes: https://lore.kernel.org/netdev/20261004122616.56714cbd@nargothrond/ Signed-off-by: Eric Dumazet Reviewed-by: Michael Chan Link: https://patch.msgid.link/20261007051747.455273-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11a03ce3c4a62d84c10ccdfe47f8075006498568 Author: Eric Dumazet Date: Thu Oct 1 22:12:53 2026 +0000 ipv4: free inet_opt and ireq_opt after an RCU grace period commit e3f33b0a1d89d738e2b913dab519226eaf76e15b upstream. tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch. Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.") Reported-by: Xinyang Ge Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20261001221253.2964024-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2f4a15c52a552c5244ec27f4ca8bda855594f918 Author: Fuad Tabba Date: Tue Oct 6 12:24:21 2026 -0400 KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT [ Upstream commit 4bdd2b3a708c1feb701cb8b62feb8ad2fd77bb07 ] FGUs don't actually require hardware support, so don't gate fgt trap config insertion on FGT. This is the only action required to allow FGUs always, as kvm_calculate_traps() already computes the FGU bits with or without FEAT_FGT. This also fixes a spurious WARN when a TLBI OS is run on a guest in vEL1 without FEAT_TLBIOS on non FEAT_FGT hardware. In this configuration the course-grained HCR_EL2.TTLBOS trap reaches the handler handle_tlbi_el1(), which expects an EL1 TLBI only from vEL2. With FGUs enabled the UNDEF will be injected without needing the specific handler. Fixes: f5a5a406b4b8b ("KVM: arm64: Propagate and handle Fine-Grained UNDEF bits") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260929090031.3829185-2-fuad.tabba@linux.dev [oliver: Take Wei-Lin's suggested changelog] Signed-off-by: Oliver Upton [ sashal: adapted the in-loop hardware-check removal to the pre-loop goto check_mcb and its unused label. ] Signed-off-by: Sasha Levin commit 44dc998c38fb5e153c3ed5665f1112661841c3f5 Author: Guixin Liu Date: Tue Oct 6 12:16:05 2026 -0400 nvme-multipath: set BLK_FEAT_ZONED only after the zone info is known [ Upstream commit 4a5e49ba0abb8b4328d6318c9aef0c0121f95507 ] The namespace head is marked zoned at allocation time based only on the command set identifier. If the zone info query reports a zero zone size, the path namespace is registered without zoned limits while the head still advertises the zoned capability with a zone size of zero, and reporting zones or writing to the head then shifts by ilog2(0). Drop the zoned feature from the head allocation and let the head limits refresh stack it in from the path namespace instead. Fixes: 28982ad73d6a ("nvme: set BLK_FEAT_ZONED for ZNS multipath disks") Fixes: 3838e80fcfb3 ("nvme: skip the zoned limits update if the zone info query failed") Cc: stable@vger.kernel.org Signed-off-by: Guixin Liu Signed-off-by: Keith Busch [ sashal: Made the existing `max_zone_append_sectors = 0` assignment unconditional to satisfy queue-limit validation. ] Signed-off-by: Sasha Levin commit 5888d38beee093fcbb98a15cfaabde110477968c Author: Han Xu Date: Tue Oct 6 11:56:09 2026 -0400 mtd: spinand: Enable QE on all dies [ Upstream commit 63d6cace2c4a7f36c1cb44f1bb5e0f3ef19e5c7f ] The QUAD ENABLE (QE) bit is stored in a per-die configuration register on some SPI-NAND devices. When a device contains multiple dies, updating the QE bit only on the currently selected die can leave the remaining dies operating in non-quad mode.   Iterate over all targets and update the QE setting on each die during initialization to ensure consistent quad I/O operation across the entire device. Tested on ISSI IS38SMW04G8B. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Han Xu Signed-off-by: Miquel Raynal [ sashal: Retained spinand_init_quad_enable()’s internal QE decision instead of using the upstream enable parameter. ] Signed-off-by: Sasha Levin commit 7bb2a5bd4f07192fca35644fab7d49a17bfbc861 Author: Zhao Li Date: Tue Oct 6 13:56:38 2026 -0400 wifi: mac80211: shut down RX BA session timer on teardown [ Upstream commit e588e83e5c7a0f6d7a77dbbb58927c8c8cfd598e ] Tearing down an RX BA session can leave the session timer queued on a freed tid_rx. Later timer-wheel processing and the timer callback itself then run against freed memory. An RX BAR handler can dereference tid_rx under RCU before teardown unpublishes it and stay in its read-side critical section while teardown deletes the session timer. The stale handler can then rearm the timer after timer_delete_sync() returns and before the RCU callback frees tid_rx. Use timer_shutdown_sync() so rearm attempts become ineffective once teardown starts. Keep reorder_timer unchanged: teardown marks the session removed under reorder_lock and its release path checks that state before rearming. session_timer has no equivalent guard because ieee80211_rx_h_ctrl() rearms it before taking reorder_lock. Fixes: a87f736d942c ("mac80211: use RCU for RX aggregation") Cc: stable@kernel.org # 5.15+ Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Signed-off-by: Johannes Berg [ sashal: Adapted the replacement to the existing del_timer_sync() call instead of timer_delete_sync(). ] Signed-off-by: Sasha Levin commit 3c765fd5212c1bbc71568b1518a7ec963a7040b4 Author: Nuno Sá Date: Tue Oct 6 12:24:14 2026 -0400 mtd: spinand: fix NULL pointer dereference with no ECC engine [ Upstream commit b890e6163761ddb580cc74f43e15f8bbde15647e ] When "nand-no-ecc-engine" is set in DT, nanddev_get_ecc_engine() takes the NAND_ECC_ENGINE_TYPE_NONE path and returns success while leaving nand->ecc.engine NULL. The SPI-NAND code nevertheless dereferences it unconditionally to test for a pipelined engine, so probing such a device oopses immediately. Rather than open-coding the test three times, add a nand_ecc_is_pipelined() helper to the NAND core that folds the NULL check into the integration comparison, and use it everywhere. Future callers then cannot reintroduce the problem. Fixes: f9d7c7265bcf ("mtd: spinand: Create direct mapping descriptors for ECC operations") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal [ sashal: Replaced the nand_ecc_is_pipelined() helper with an inline NULL guard in spinand_create_dirmap(). ] Signed-off-by: Sasha Levin commit d32f0b52101db54c481a64a74afba9e55f9e019e Author: Timur Kristóf Date: Mon Oct 5 08:40:03 2026 -0400 drm/amd/display: Mark DCE 6.4 as not APU [ Upstream commit 3a52d587d1fc8e8bf94ba1b07374f7ec91aaffb4 ] DCE 6.4 is found in Oland chips, which were advertised as low-end gaming GPUs in 2013~2015 and then have been sold as low-end workstation GPUs until 2017~2019. These are not APUs. Fixes: 7c15fd86aaec ("drm/amd/display: dc/dce: add initial DCE6 support (v10)") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-3-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 1072aa811ea1e61d5f763e4ec1bc6d24bb61f14a) Cc: stable@vger.kernel.org [ sashal: Adjusted patch context for the older source layout with missing initialization lines. ] Signed-off-by: Sasha Levin commit 03ab8281998d44902af6eb0c40ac1c31d3cdd5d4 Author: Abdurrahman Hussain Date: Mon Oct 5 18:47:33 2026 -0400 i2c: xiic: preserve PEC byte length in SMBus block read setup [ Upstream commit b7e6df2f52ed5c02838832f53c171a5645f9b376 ] xiic_smbus_block_read_setup() recalculates i2c->rx_msg->len based on the length byte returned by the device, but historically clobbered the PEC byte expectation the SMBus core had baked into msg->len. That dropped the PEC byte from the caller's buffer on the normal and chunked receive-fifo branches. Compute pec_len up-front as (i2c->rx_msg->len - 1) -- the trailing bytes the caller has already accounted for beyond the length byte, 1 when the SMBus core enabled PEC, and possibly more for an I2C_M_RECV_LEN request coming from i2c-dev -- and add it to the new length in every branch: - chunked: the trailing bytes do not fit in the Rx FIFO, so drain in chunks. The guard becomes (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH) rather than rxmsg_len alone, both because pec_len bytes also have to fit and because it is what bounds rfd_set in the else branch below to the 4 bits of XIIC_RFD_REG_OFFSET. - padded (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN): the hardware needs at least 3 bytes on the bus to exit the read cleanly (the second byte is already being clocked in by the time the ISR reads the length byte and is too late to NACK), so we still pad rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN. The dummy trailing byte that gets drained must then be trimmed off before handing the message back to the SMBus core; otherwise i2c_smbus_check_pec() reads buf[len-1] (= dummy) instead of the real PEC byte at buf[1] and rejects every clean zero-length block read with -EBADMSG. Record the true valid byte count in a new field i2c->smbus_actual_len and trim rx_msg->len down to it in xiic_smbus_trim_len(), called from both completion sites that clear rx_msg: xiic_process()'s RX_FULL branch and xiic_recv_atomic(), which drains the FIFO with interrupts off. smbus_actual_len is per-receive state, so xiic_start_recv() clears it before every receive. Only the padded branch ever sets it, and a block read aborted by arbitration loss or a TX error never reaches the completion site, so without that clear a stale value would trim the length of an unrelated later read. The condition is expressed in total bytes rather than the old "(rxmsg_len == 1) || (rxmsg_len == 0)" so that a request carrying more than one trailing byte does not get padded: padding records a length the drain never reaches, which would hand the caller a byte that was never received. - normal: all trailing bytes fit in one FIFO fill. rfd_set gains pec_len for the same reason the length does. Because the padded branch above has already taken every case with fewer than SMBUS_BLOCK_READ_MIN_LEN total bytes, rxmsg_len + pec_len is at least 2 here and the subtraction cannot underflow the u8. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-1-df7e752332ef@nexthop.ai [ sashal: Inlined length trimming in xiic_process() to accommodate missing atomic-transfer support. ] Signed-off-by: Sasha Levin commit 92862efb0df1a895ef286a18d2d34c9d1f924818 Author: Manikanta Guntupalli Date: Mon Oct 5 18:47:32 2026 -0400 i2c: xiic: Relocate xiic_i2c_runtime_suspend and xiic_i2c_runtime_resume to facilitate atomic mode [ Upstream commit 2ee409c6a12d74cd1b16ca3690baa7d5ffffeb7d ] Relocate xiic_i2c_runtime_suspend and xiic_i2c_runtime_resume functions to avoid prototype statements in atomic mode changes. Signed-off-by: Manikanta Guntupalli Acked-by: Michal Simek Link: https://lore.kernel.org/r/20241210095242.1982770-2-manikanta.guntupalli@amd.com Signed-off-by: Andi Shyti Stable-dep-of: b7e6df2f52ed ("i2c: xiic: preserve PEC byte length in SMBus block read setup") Signed-off-by: Sasha Levin commit 7db6b8a1ca70700114fbebfd49856da07811ee66 Author: Aaron Kling Date: Mon Oct 5 18:24:41 2026 -0400 ALSA: hda/tegra: Re-enable SDO workaround for Tegra194 [ Upstream commit 89365897f4210979966aa808d7b013edf4080558 ] This workaround was originally added for Tegra194, but no longer gets applied for it. Commit 615d43540043 ("ALSA: hda/tegra: fix tegra-hda on tegra30 soc") changed the guard to tegra30-hda, which worked because all affected archs had the fallback compatible. However, commit 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") removed the fallback compatible for Tegra194, causing this to break. Fixes: 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aaron Kling Link: https://patch.msgid.link/20260926-tegra194-hda-sdo-v1-1-f7a636a07a58@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4cfd685b9b6bc47c06633d85f7c993c4c7d7f03e Author: Ian Rogers Date: Mon Oct 5 17:31:44 2026 -0400 perf: Replace perf_event_header__init_id with full header init [ Upstream commit b9d1fdc6f4ac1b6e49f9deafaf137da1407d9af1 ] perf_iterate_sb() invokes its callback for each matching perf_event on the CPU and task context, passing a shared caller-allocated event structure. perf_event_header__init_id() mutated header->size in place by adding event->id_header_size, requiring sideband output callbacks to save and restore header fields across iterations. Three sideband callbacks failed to save and restore header.size around perf_event_header__init_id(): - perf_event_ksymbol_output() - perf_event_bpf_output() - perf_event_text_poke_output() When multiple events with attr.ksymbol, attr.bpf_event, or attr.text_poke and sample_id_all are active on the same CPU, each subsequent event receives a record whose header.size is inflated by all preceding events' id_header_size values while only a single id_sample is written, leaving uninitialized ring-buffer bytes at the end of the record and causing userspace perf to fail with -EFAULT ("Bad address") when parsing the sample_id trailer. Similarly, perf_event_mmap_output() set PERF_RECORD_MISC_MMAP_BUILD_ID in mmap_event->event_id.header.misc when event->attr.build_id was enabled, but only saved and restored header.size and header.type. If an event with attr.build_id was followed by an event with attr.mmap2 and !attr.build_id, the second event received PERF_RECORD_MISC_MMAP_BUILD_ID in header.misc while its payload contained maj/min/ino/ino_generation instead of a build ID. Rather than splitting header initialization between callers and output callbacks and saving/restoring mutated header fields, replace perf_event_header__init_id() with perf_event_header__init(), which initializes header->type, header->misc, and header->size alongside the sample_id fields on each invocation. Fixes: 76193a94522f ("perf, bpf: Introduce PERF_RECORD_KSYMBOL") Fixes: 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT") Fixes: e17d43b93e54 ("perf: Add perf text poke event") Fixes: 88a16a130933 ("perf: Add build id data in mmap2 event") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260929222332.973435-1-irogers@google.com Cc: stable@vger.kernel.org [ sashal: Omitted deferred callchain changes because that support is absent. ] Signed-off-by: Sasha Levin commit 7106b70409598b7a129c76a9bbb5af8b43f5b26c Author: Daniel Starke Date: Mon Oct 5 16:15:39 2026 -0400 tty: n_gsm: fix missing modem controls after DLCI open in convergence layer type 2 [ Upstream commit 11ea5a63d30ad6d305b1c22301cd99ff45a98c8d ] The current implementation only updates the virtual V.24 control signals after DLCI open in basic option mode. In advanced option mode with convergence layer type 2 an empty data frame needs to be transmitted to inform the peer about the initial virtual V.24 control signals. Not doing so has two unwanted side effects: 1. hardware flow control status is unclear (initial CTS line is unknown) 2. DLCI user presence is not transmitted (initial DTR line is unknown) Applications waiting on these lines can not start after a DLCI has been opened until the first data frame has been transmitted. Fix this by using gsm_modem_update() thoroughly which handles basic and advanced option mode correctly. Add a flag in gsm_modem_update() and the delegated gsm_modem_upd_via_msc() to control whether waiting for the MSC command response is possible. Remove obsolete gsm_modem_send_initial_msc(). Fixes: 3cf0b3c243e5 ("tty: n_gsm: Don't block input queue by waiting MSC") Cc: stable Signed-off-by: Daniel Starke Link: https://patch.msgid.link/20260826063026.2472-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman [ sashal: Adjusted context to match the @dlci parameter comment without a colon. ] Signed-off-by: Sasha Levin commit 34d4f67472ef7a744970b772a8565ddc727788e2 Author: Johan Hovold Date: Mon Oct 5 13:17:54 2026 -0400 tty: tty_port: restore TTY_IO_ERROR on activation failure [ Upstream commit 56964f6a31238fb41d5830bb42520c5b10ff7d8f ] Make sure to restore the TTY_IO_ERROR flag if activation fails to prevent I/O attempts on a port that is gone or powered down. This specifically avoids issues like kernel panic due to unclocked accesses or NULL-pointer dereferences when accessing powered down or deregistered ports when a TTY ioctl races with hangup and open. Note that the flag is set again in tty_port_close() but not restoring it on activation failure leaves a window where drivers fail to handle the ioctl-hangup race. Fixes: a9a37ec33a1b ("tty: tty_port: Move the IO_ERROR clear") Cc: stable # 2.6.33 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260908084000.218528-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 55a047d520dc0c6a522827a6f4d3c2301bfed839 Author: Jiri Slaby (SUSE) Date: Mon Oct 5 13:17:53 2026 -0400 tty: tty_port: use guard()s [ Upstream commit 88d65e22c8bf7a4b6d61098d67727d14f1c5930f ] Having all the new guards, use them in the tty_port code. This improves readability, makes error handling easier, and marks locked portions of code explicit. Signed-off-by: "Jiri Slaby (SUSE)" Link: https://lore.kernel.org/r/20250814072456.182853-6-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 56964f6a3123 ("tty: tty_port: restore TTY_IO_ERROR on activation failure") Signed-off-by: Sasha Levin commit cb02eb97afcc3280da4ba2dc530fe46ec26a61f1 Author: Jiri Slaby (SUSE) Date: Mon Oct 5 13:17:52 2026 -0400 tty: introduce tty_port_tty guard() [ Upstream commit e8398b8aed50382c21fcec77e80a5314e7c45c25 ] Having this, guards like these work: scoped_guard(tty_port_tty, port) tty_wakeup(scoped_tty()); See e.g. "tty_port: use scoped_guard()" later in this series. The definitions depend on CONFIG_TTY. It's due to tty_kref_put(). On !CONFIG_TTY, it is an inline and its declaration would conflict. The guards are not needed in that case, of course. Signed-off-by: "Jiri Slaby (SUSE)" Link: https://lore.kernel.org/r/20250814072456.182853-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 56964f6a3123 ("tty: tty_port: restore TTY_IO_ERROR on activation failure") Signed-off-by: Sasha Levin commit ff12b99a8437fbe4d151591b93e3d99fdb404775 Author: Pannarat Wiriyaarritham Date: Mon Oct 5 13:17:20 2026 -0400 usb: typec: ucsi: acpi: Assume UCSI 1.2 on Acer Nitro ANV15-41 [ Upstream commit 8c51ea651d043c786c37668c51624bd6b338a0ef ] The Acer Nitro ANV15-41 exposes a functional UCSI ACPI PPM but reports a UCSI VERSION value of zero. ucsi_register() rejects a zero version with -ENODEV, leaving the system without registered USB Type-C connectors. The PPM works correctly when using the UCSI 1.2 layout. With UCSI 1.2 assumed, both Type-C connectors register correctly and USB Power Delivery negotiation works. Add a DMI-specific UCSI operation for the Acer Nitro ANV15-41 that substitutes UCSI 1.2 only when firmware reports a zero version. Preserve any valid non-zero firmware version. Tested on an Acer Nitro ANV15-41 with BIOS V1.51. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable Assisted-by: LLM Signed-off-by: Pannarat Wiriyaarritham Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260910023338.31816-1-pannarat.wiriyaarritham@danielcorp.dev Signed-off-by: Greg Kroah-Hartman [ sashal: Omitted the .write_message_out initializer because the older ucsi_operations interface lacks that member. ] Signed-off-by: Sasha Levin commit 092e0bd4eb80ae27ba57b39fbcb4598455781654 Author: Arthur Heymans Date: Mon Oct 5 12:17:48 2026 -0400 drm/amd/display: Preserve eDP mode on initial ASSR failure [ Upstream commit 5e08102d1d336593160d1434261d50b0c0f6cbe6 ] Commit 56d8ce9d8c17 ("drm/amd/display: Apply correct panel mode when reinitializing hardware") made ASSR failure fall back to the default panel mode unless eDP mode had previously been applied. However, dc_link is zero-initialized and DP_PANEL_MODE_DEFAULT is zero. Before the first call to dp_set_panel_mode(), panel_mode therefore looks like a previously applied default mode. If ASSR setup fails during the first link training attempt, the driver incorrectly trains the eDP link using the default scrambling mode. On a Google Vilboz Chromebook running self-built coreboot firmware and PSP verstage, this leaves the panel mostly black with corrupted output along the top edge. Track whether panel_mode has actually been initialized, and only consult the saved mode after it has been applied. This retains the recovery behavior while preserving eDP mode during initial link training. Fixes: 56d8ce9d8c17 ("drm/amd/display: Apply correct panel mode when reinitializing hardware") Assisted-by: Pi:gpt-5.6-sol Reviewed-by: George Zhang Reviewed-by: Alex Hung Signed-off-by: Arthur Heymans Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ccb6c2702033f1002b45807fb3cc938760f26f78) Cc: stable@vger.kernel.org # 6.4.x [ sashal: Adjusted context for the different eDP panel-mode logging format. ] Signed-off-by: Sasha Levin commit 441be312fce927443eae2821f502344d953c38bb Author: Runyu Xiao Date: Mon Oct 5 10:49:47 2026 -0400 USB: dwc2: shut down wakeup timer before freeing HCD state [ Upstream commit fd772af9512cdecb83de34a461801533828e77fd ] dwc2_wakeup_detected() accesses the DWC2 host state and can rearm the wakeup timer. dwc2_hcd_free() currently deletes the timer only after freeing host-owned state, and timer_delete() does not synchronize a callback or prevent it from being queued again. Stop and shut down the timer in dwc2_hcd_release(), before the HCD resources are freed. This covers both the HCD initialization error path and normal HCD removal. Fixes: 7359d482eb4d ("staging: HCD files for the DWC2 driver") Cc: stable Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Reviewed-by: Thinh Nguyen Link: https://patch.msgid.link/20260904065323.4047026-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman [ sashal: Adapted timer_delete() removal to the existing del_timer() call. ] Signed-off-by: Sasha Levin commit c4aa39ad14b81e1e122ae8e6684014ae7a4c593a Author: Myeonghun Pak Date: Mon Oct 5 10:30:20 2026 -0400 usb: ohci-spear: disable controller wakeup on removal [ Upstream commit b1b0f8bdbbc891a4ee7f3b1a878c633e02b7bbeb ] Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-4-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3acdfde18964adaf0a1976f590c8d35648823115 Author: Chen Ni Date: Mon Oct 5 10:30:19 2026 -0400 usb: ohci-spear: Remove unnecessary NULL check before clk_disable_unprepare() [ Upstream commit a891b9aebcc7406fe2f439d184bac3948fb08645 ] clk_disable_unprepare() already checks NULL by using IS_ERR_OR_NULL. Remove unneeded NULL check for clk here. Signed-off-by: Chen Ni Acked-by: Alan Stern Link: https://lore.kernel.org/r/20250617042050.1930940-1-nichen@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Stable-dep-of: b1b0f8bdbbc8 ("usb: ohci-spear: disable controller wakeup on removal") Signed-off-by: Sasha Levin commit 71b7c3d26848e05a34d8bccb2e17334cafd330d3 Author: Francisco Beltrán Millalén Date: Mon Oct 5 09:48:01 2026 -0400 drm/amdgpu: reset VI ASIC on MacBookPro14,3 [ Upstream commit a22e5e4f2ebbdbb962cc3233094d189c4dfaa051 ] On a MacBookPro14,3 with a Radeon Pro 555 (Polaris11), the framebuffer is at MC address 0 when amdgpu loads after a cold boot, as the firmware leaves it (MC_VM_FB_LOCATION = 0x007f0000), while the VBIOS ASIC_Init table places it at 0xF4_0000_0000 (0xf47ff400). amdgpu reads the location once, at init, so after a re-POST (S3 resume or GPU reset) the framebuffer has moved and the driver keeps programming the old one: the SMU is handed a table that was never written and the GPU does not come back, which leaves the internal panel black. Resetting the ASIC on load makes ASIC_Init run before the driver reads the location, so the driver uses the VBIOS placement from the start and every later re-POST puts the framebuffer back where it already is. Add the Radeon Pro 555 used in this machine to the existing VI reset quirk table. Tested on a MacBookPro14,3 on 6.18.49 with the quirk table backported (the kernel also carries unrelated local PCI and ACPI patches for this machine). The framebuffer is at 0x000000F400000000 after both cold and warm boot, and the GPU survived 9 S3 cycles (lid close and rtcwake, one of them with the lid closed for about 7.5 minutes and a USB-C disk attached), each followed by a few minutes of 3D load; no ring timeouts or VM faults were reported. The reset adds about 0.23 s to amdgpu init. Suggested-by: Christian König Suggested-by: Alex Deucher Link: https://lore.kernel.org/all/20260924132952.25054-1-fbeltranmillalen@gmail.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Francisco Beltrán Millalén Signed-off-by: Alex Deucher (cherry picked from commit b6b1d97218518003107d4446fac278fa3e0a19a0) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 764480af483d36b7a0adb901cf45a31ad142b608 Author: Andre Eikmeyer Date: Mon Oct 5 09:48:00 2026 -0400 drm/amdgpu: reset VI ASIC on MacBookPro15,1 [ Upstream commit a5be7ad8f5f0e067613e9197638f216f46252946 ] After S3, reloading amdgpu on MacBookPro15,1 systems with a Radeon Pro 555X or 560X fails while loading the SMU firmware. The existing SMC register check does not request a reset because the registers do not reliably reflect the stale SMU state on these machines. Frederick Morlock found that forcing a VI ASIC reset allows the driver to initialize again. This patch limits his workaround to the exact PCI device, Apple subsystem device and revision combinations used by these two GPUs, leaving other VI hardware unchanged. Suggested-by: Frederick Morlock Signed-off-by: Andre Eikmeyer Signed-off-by: Alex Deucher Stable-dep-of: a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3") Signed-off-by: Sasha Levin commit 80e318b8e5592743886f694994a9839506e6b211 Author: Eric Biggers Date: Tue Oct 6 23:46:21 2026 +0200 fsverity: add dependency on 64K or smaller pages commit a300000233a9ff842e2fb450fb9a79f7827a586d upstream. Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller. 64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used. For now, just disable support for FS_VERITY in these odd configurations to ensure it isn't used in cases where it would have incorrect behavior. Fixes: 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing") Reported-by: Christoph Hellwig Closes: https://lore.kernel.org/r/20260119063349.GA643@lst.de Reviewed-by: Theodore Ts'o Link: https://lore.kernel.org/r/20260221204525.30426-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 2f567404414f04655cba3ecc8b3c196034490945 Author: Mostafa Saleh Date: Tue Oct 6 13:56:16 2026 -0400 KVM: arm64: Use stage-1 leaf size for VM_PFNMAP [ Upstream commit 71cc2c67fb8f8d5aa8154eb482e9846d2214f11b ] When commit 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO") added VM_PFNMAP support to get_vma_page_shift(), stage-1 page tables did not support huge PFNMAP (as in VFIO-PCI vfio_pci_mmap_huge_fault()) and transparent_hugepage_adjust() was unsafe for MMIO as it dereferenced struct page. Since commit 6011cf68c885 ("KVM: arm64: Walk userspace page tables to compute the THP mapping size"), transparent_hugepage_adjust() instead walks the host stage-1 page tables via get_user_mapping_size() without touching struct page. Meanwhile, commit 3e509c9b03f9 ("mm/arm64: support large pfn mappings") enabled stage-1 huge PFNMAP. So. we can drop the VMA-based VM_PFNMAP size calculation in get_vma_page_shift() and let transparent_hugepage_adjust() derive the stage-2 mapping size directly from the populated stage-1 leaf for non-cacheable mappings as well. Assisted-by: LLM Cc: stable@vger.kernel.org Fixes: 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO") Reviewed-by: Marc Zyngier Signed-off-by: Mostafa Saleh Signed-off-by: Oliver Upton [ sashal: Adapted upstream’s split fault-helper changes to the existing user_mem_abort() implementation. ] Signed-off-by: Sasha Levin commit a9eecf9bc7b2df4ea9a4211c001f8ed41552506a Author: Beata Michalska Date: Mon Oct 5 20:29:48 2026 -0400 arm64: errata: Add Cortex-A725 erratum 3821522 workaround [ Upstream commit 45f7304679875eb000d67e194090ee7abd05c89c ] Cortex-A725 erratum 3821522 affects the CNT_CYCLES event, which can incur a significant increment error when a CPU enters and subsequently exits WFE or WFI, and may no longer track the system counter frequency. The AMEVCNTR01_EL0 counter is used as the AMU constant counter for frequency invariance and CPPC FFH feedback counters. Wire the affected Cortex-A725 range into the shared broken AMU constant-counter capability so the affected counter is treated as unavailable by returning zero in the AMU counter paths. This prevents the broken counter from being used as a reference source. The erratum can also affect PMUv3 users of the CNT_CYCLES event, but this workaround intentionally does not change PMU event handling. Hiding or rejecting the PMU event from the erratum code would change the perf-visible PMU event interface, including raw event selection, and would need a separate PMU-specific approach rather than being folded into the AMU reference-counter workaround. Cc: stable@vger.kernel.org Signed-off-by: Beata Michalska Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 9a18b2ff1c0746bfe9fbededcf44f43b609a20b5 Author: Beata Michalska Date: Mon Oct 5 20:29:47 2026 -0400 arm64: errata: Factor out broken AMU const counter cap [ Upstream commit 573371caf7aea8582212da81dcead2c3f48fac4b ] Move the workaround from the erratum 2457168-specific cpucap to a generic broken AMU constant-counter one. This keeps the existing Cortex-A510 handling unchanged while allowing other errata with similar AMU constant counter issue to share the capability bit and call sites. Signed-off-by: Beata Michalska Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon Omit the comment-only update to the paired AMU counter reader, which is absent here. Retain the shared capability, CPU matching list, and the checks in the existing counter-read and frequency-invariance paths. Stable-dep-of: 45f730467987 ("arm64: errata: Add Cortex-A725 erratum 3821522 workaround") Signed-off-by: Sasha Levin commit 1e11412a1b9854a89d044576d616675b16141d87 Author: Chengfeng Ye Date: Tue Oct 6 04:09:08 2026 -0400 Bluetooth: Serialize SMP remote OOB data access [ Upstream commit 81a2345f1984f0b36d3226571bc196316a01b648 ] build_pairing_cmd() looks up remote OOB data and copies its contents without holding hdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list. KASAN reported: BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0 Call Trace: build_pairing_cmd+0x948/0x9b0 smp_recv_cb+0x459f/0x8110 l2cap_recv_frame+0xf14/0x9190 l2cap_recv_acldata+0xa64/0xd40 hci_rx_work+0x4ca/0x730 Allocated by task 87: hci_add_remote_oob_data+0x11d/0x530 add_remote_oob_data+0x282/0x400 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 93: hci_remote_oob_data_clear+0x108/0x1c0 remove_remote_oob_data+0x198/0x220 hci_sock_sendmsg+0x1033/0x1ea0 Taking hdev->lock in build_pairing_cmd() would recurse for callers that already hold it and invert the device-to-L2CAP lock order on the receive path. Add a per-device remote_oob_lock instead, held across the SMP lookup and copies and by the add, remove and clear helpers. Cover initialization and in-place updates as well, so SMP cannot read partially initialized or updated OOB values. Release the mutex on allocation failure, preserving the existing error return. The new critical sections acquire no device, connection or channel locks. Writers retain their existing hdev->lock protection, which continues to serialize the other readers without changing their locking or behavior. Link: https://lore.kernel.org/r/00660cd3-7d71-13a4-f617-229e6defb701@gmail.com Fixes: 02b05bd8b0a6 ("Bluetooth: Set SMP OOB flag if OOB data is available") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz [ sashal: adjusted context for kmalloc() instead of kmalloc_obj() ] Signed-off-by: Sasha Levin commit 101825c09ad6b7daa6cf4c9e6b1720b13de15596 Author: Chengfeng Ye Date: Tue Oct 6 04:08:59 2026 -0400 Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown [ Upstream commit 848a7a91c7f03675d3bd8db6f7721cbf9cb50e21 ] hci_low_sent() selects a connection under RCU but drops the read lock before calculating its quota and returning it to the scheduler. The connection is then used without lifetime protection by hci_sched_iso() and hci_sched_sco(). After the TX worker drops the RCU read lock, hci_abort_conn_sync() on hdev->req_workqueue can remove the connection from the hash, complete synchronize_rcu(), purge its queues and release it. The TX worker on hdev->workqueue can then access the freed connection in hci_quote_sent() or while dequeuing packets and updating conn->sent. KASAN reported: BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840 Workqueue: hci0 hci_tx_work Call Trace: hci_low_sent+0x730/0x840 hci_sched_iso+0x25e/0x4d0 hci_tx_work+0x239/0xcb0 Allocated by task 93: __hci_conn_add+0x16f/0x1b40 hci_bind_bis+0x782/0x17b0 hci_connect_bis+0xa0/0x510 iso_sock_connect+0x589/0x1050 Freed by task 88: kfree+0x131/0x3c0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x55a/0xe80 hci_disconnect_sync+0x156/0x180 hci_abort_conn_sync+0x3e7/0x940 hci_cmd_sync_work+0x13c/0x290 Hold hci_dev_lock() across connection selection and transmission in both SCO and ISO scheduling, serializing them with connection teardown. This also prevents queuing completion timestamps after the connection queues have been purged. Extending RCU across transmission would be unsafe because the transmit path can sleep. Keep the ISO timeout check outside the mutex since hci_link_tx_to() takes it itself. The preceding channel fix already holds this mutex in the ACL and LE schedulers, which call the SCO scheduler between packets. Move the SCO body to __hci_sched_sco(), assert that its caller holds the mutex, and use it directly from these locked paths. Keep a locking hci_sched_sco() wrapper for the direct calls from hci_tx_work(). This avoids recursively acquiring the device mutex while preserving the scheduling order. Remove the obsolete claim that connection removal disables TX. Fixes: bf4c63252490 ("Bluetooth: convert conn hash to RCU") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz [ sashal: Adjusted hci_sched_iso() lock placement around existing ISO/LE/ACL credit selection with no ISO timeout check. ] Signed-off-by: Sasha Levin commit f2338929c7663859c0c74dd6fef2c0245066f845 Author: Mark Rutland Date: Thu Oct 1 14:08:36 2026 +0100 arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems [ Upstream commit e060d9069b49fe55f38057dfe592068014652671 ] When system_supports_sme() is true but system_supports_sve() is false, restoring a specifically crafted SVE signal context can result in the task erroneously having non-streaming SVE state. Subsequent attempts to manipulate the task's FPSIMD/SVE/SME state can result in a variety of problems, including fatal EL1 UNDEFs. In such configurations, the kernel always creates an SVE signal context when delivering a signal, and this can only be in one of two states: (1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing streaming mode SVE state. The recorded VL is the task's live streaming VL. (2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The FPSIMD context contains the non-streaming mode FPSIMD state. The recorded VL is 0. Currently restore_sve_fpsimd_context() correctly rejects cases where SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is present. Consequently, restore_sve_fpsimd_context() can place the task in a state where it has non-streaming SVE state even when this is not supported by HW. For example, this can cause a later EL1 UNDEF when the kernel attempts to restore the task's ZCR_EL1 value: | # ./sme-sigcontext-to-sve | Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 131 Comm: sme-sigcontext- Not tainted 7.3.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : fpsimd_restore_current_state+0x258/0x458 | lr : exit_to_user_mode_loop+0xb8/0x188 | sp : ffff80008056be40 | x29: ffff80008056be40 x28: fff00000c1670000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80008056bec0 x22: 0000000000000008 x21: 0000000000000040 | x20: 0000000000000081 x19: 0000000008800010 x18: 0000000000000000 | x17: 0000fffffd412570 x16: 0000000000001000 x15: 0000fffffd4123b0 | x14: 0000fffffd412780 x13: 0000fffffd412be8 x12: 0000000047435300 | x11: 0000fffffd412570 x10: 0000000000000000 x9 : 0000000045585401 | x8 : fff00000c18a6c44 x7 : 0000000000000000 x6 : 0000000000000002 | x5 : 0000000000000002 x4 : ffff800080568000 x3 : 0000000000000001 | x2 : 0000000008800010 x1 : fff00000c1670000 x0 : 0000000008800000 | Call trace: | fpsimd_restore_current_state+0x258/0x458 (P) | exit_to_user_mode_loop+0xb8/0x188 | el0_svc+0x1cc/0x1d0 | el0t_64_sync_handler+0xa0/0xe4 | el0t_64_sync+0x198/0x19c | Code: d5384101 f9400020 53175c03 36b80de0 (d5381202) | ---[ end trace 0000000000000000 ]--- | Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt | Kernel Offset: 0x291fb1000000 from 0xffff800080000000 | PHYS_OFFSET: 0x40000000 | CPU features: 0x0,00000000,0052802f,ffb88f43,3afcf73f | Memory Limit: none Rework restore_sve_fpsimd_context() to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is not present. As parse_user_sigframe() rejects SVE signal frames when neither SVE nor SME are supported, it isn't necessary for restore_sve_fpsimd_context() to handle the case where neither are supported. Fixes: 7dde62f0687c ("arm64/signal: Always accept SVE signal frames on SME only systems") Signed-off-by: Mark Rutland Reviewed-by: Mark Brown Cc: Catalin Marinas Cc: Will Deacon Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e8fba015559bb075c5f5385962377de76ac4f9fd Author: Mark Rutland Date: Thu May 8 14:26:24 2025 +0100 arm64/fpsimd: signal: Consistently read FPSIMD context [ Upstream commit be625d803c3bbfa9652697eb57589fe6f2f24b89 ] For historical reasons, restore_sve_fpsimd_context() has an open-coded copy of the logic from read_fpsimd_context(), which is used to either restore an FPSIMD-only context, or to merge FPSIMD state into an SVE state when restoring an SVE+FPSIMD context. The logic is *almost* identical. Refactor the logic to avoid duplication and make this clearer. This comes with two functional changes that I do not believe will be problematic in practice: * The user_fpsimd_state::size field will be checked in all restore paths that consume it user_fpsimd_state. The kernel always populates this field when delivering a signal, and so this should contain the expected value unless it has been corrupted. * If a read of user_fpsimd_state fails, we will return early without modifying TIF_SVE, the saved SVCR, or the save fp_type. This will leave the task in a consistent state, without potentially resurrecting stale FPSIMD state. A read of user_fpsimd_state should never fail unless the structure has been corrupted or the stack has been unmapped. Suggested-by: Will Deacon Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Link: https://lore.kernel.org/r/20250508132644.1395904-5-mark.rutland@arm.com [will: Ensure read_fpsimd_context() returns negative error code or zero] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ea3c64065cf8bd3736e831c1d5e923f936de1176 Author: Mark Rutland Date: Thu May 8 14:26:23 2025 +0100 arm64/fpsimd: signal: Mandate SVE payload for streaming-mode state [ Upstream commit b465ace42620970e840c7aeb2c44a6e3b1002fec ] Non-streaming SVE state may be preserved without an SVE payload, in which case the SVE context only has a header with VL==0, and all state can be restored from the FPSIMD context. Streaming SVE state is always preserved with an SVE payload, where the SVE context header has VL!=0, and the SVE_SIG_FLAG_SM flag is set. The kernel never preserves an SVE context where SVE_SIG_FLAG_SM is set without an SVE payload. However, restore_sve_fpsimd_context() doesn't forbid restoring such a context, and will handle this case by clearing PSTATE.SM and restoring the FPSIMD context into non-streaming mode, which isn't consistent with the SVE_SIG_FLAG_SM flag. Forbid this case, and mandate an SVE payload when the SVE_SIG_FLAG_SM flag is set. This avoids an awkward ABI quirk and reduces the risk that later rework to this code permits configuring a task with PSTATE.SM==1 and fp_type==FP_STATE_FPSIMD. I've marked this as a fix given that we never intended to support this case, and we don't want anyone to start relying upon the old behaviour once we re-enable SME. Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250508132644.1395904-4-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a8bc17a5bf3091b4d64177a7eea472d18dfec870 Author: Mark Rutland Date: Thu May 8 14:26:22 2025 +0100 arm64/fpsimd: signal: Clear PSTATE.SM when restoring FPSIMD frame only [ Upstream commit 1bf663a86a4505a97f08d06c373704de9441c891 ] On systems with SVE and/or SME, the kernel will always create SVE and FPSIMD signal frames when delivering a signal, but a user can manipulate signal frames such that a signal return only observes an FPSIMD signal frame. When this happens, restore_fpsimd_context() will restore state such that fp_type==FP_STATE_FPSIMD, but will leave PSTATE.SM as-is. It is possible for a user to set PSTATE.SM between syscall entry and execution of the sigreturn logic (e.g. via ptrace), and consequently the sigreturn may result in the task having PSTATE.SM==1 and fp_type==FP_STATE_FPSIMD. For various reasons it is not legitimate for a task to be in a state where PSTATE.SM==1 and fp_type==FP_STATE_FPSIMD. Portions of the user ABI are written with the requirement that streaming SVE state is always presented in SVE format rather than FPSIMD format, and as there is no mechanism to permit access to only the FPSIMD subset of streaming SVE state, streaming SVE state must always be saved and restored in SVE format. Fix restore_fpsimd_context() to clear PSTATE.SM when restoring an FPSIMD signal frame without an SVE signal frame. This matches the current behaviour when an SVE signal frame is present, but the SVE signal frame has no register payload (e.g. as is the case on SME-only systems which lack SVE). This change should have no effect for applications which do not alter signal frames (i.e. almost all applications). I do not expect non-{malicious,buggy} applications to hide the SVE signal frame, but I've chosen to clear PSTATE.SM rather than mandating the presence of an SVE signal frame in case there is some legacy (non-SME) usage that I am not currently aware of. For context, the SME handling was originally introduced in commit: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") ... and subsequently updated/fixed to handle SME-only systems in commits: 7dde62f0687c ("arm64/signal: Always accept SVE signal frames on SME only systems") f26cd7372160 ("arm64/signal: Always allocate SVE signal frames on SME only systems") Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Link: https://lore.kernel.org/r/20250508132644.1395904-3-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8473f44db9f710ea6f8cafb22f2e3ba6cb8ca9a7 Author: Zhengchuan Liang Date: Mon Oct 5 18:12:39 2026 -0400 perf: Require kernel access for text poke events [ Upstream commit 357e8a77a501d96c9517f01f4a211eed5e9c9184 ] Perf events with exclude_kernel=1 can be opened without kernel perf access. However, exclude_kernel does not suppress text-poke sideband records. Every PERF_RECORD_TEXT_POKE is marked PERF_RECORD_MISC_KERNEL and contains a raw kernel instruction address. An unprivileged task can therefore open and mmap a task-local software event with text_poke=1. Both opening a count-only tracepoint event and configuring UDP GRO for ESP-in-UDP cause updates to inline static calls; the observer receives the relocated addresses of the modified instructions. For a known kernel image, any such address reveals the runtime kernel text base despite KASLR. Call perf_allow_kernel() whenever attr.text_poke is set, regardless of exclude_kernel. Events that neither monitor kernel execution nor request text-poke records retain their existing permissions. Fixes: e17d43b93e54 ("perf: Add perf text poke event") Assisted-by: LLM Signed-off-by: Zhengchuan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/99131354c41e23188f778b92f90363775b482395.1790573390.git.zcliangcn@gmail.com Signed-off-by: Sasha Levin commit 132bee76097be421ab3012130b5b506324cf2be1 Author: Dapeng Mi Date: Mon Oct 5 18:12:38 2026 -0400 perf/core: Check kernel access when kernel callchains are requested [ Upstream commit a4573a3838ae4fc73b70019cfa1dac9aaea7cc2f ] perf_event_open() currently gates perf_allow_kernel() only on !attr.exclude_kernel. However, users can still request kernel callchain collection with attr.exclude_callchain_kernel == 0 even when attr.exclude_kernel == 1. That still requires kernel profiling privilege, but the existing check does not enforce it. Update the permission check to call perf_allow_kernel() when either kernel sampling is requested or kernel callchains are requested. This keeps permission checks aligned with requested data and prevents unprivileged use of kernel callchain capture. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260616044654.3468742-9-dapeng1.mi@linux.intel.com Stable-dep-of: 357e8a77a501 ("perf: Require kernel access for text poke events") Signed-off-by: Sasha Levin commit 800460cc90449a9435c42e08479d2e5a21dbecc4 Author: Luo Gengkun Date: Mon Oct 5 18:12:37 2026 -0400 perf: Remove unnecessary parameter of security check [ Upstream commit 9ec84f79c5a7a65cd69b5b705a203759665160cd ] It seems that the attr parameter was never been used in security checks since it was first introduced by: commit da97e18458fb ("perf_event: Add support for LSM and SELinux checks") so remove it. Signed-off-by: Luo Gengkun Reviewed-by: Ingo Molnar Signed-off-by: Paul Moore Stable-dep-of: 357e8a77a501 ("perf: Require kernel access for text poke events") Signed-off-by: Sasha Levin commit 1572d86bcf0bcb848d20fc5e5de7ed6963034c2b Author: Johan Hovold Date: Mon Oct 5 16:39:21 2026 -0400 tty: fix saved termios reset race [ Upstream commit 8df07fe93573e9e548d6645273e9bcb6eb74059e ] Resetting saved termios state on device registration is needed where a minor number can be reused for an entirely different device and where the old settings may prevent the port from even being opened (e.g. when CLOCAL is not set). Not all TTY drivers guarantee that the minor number is no longer in use when registering devices however, something which can lead to a use-after-free when closing a TTY (and saving its termios) races with re-registration. Add a new TTY_DRIVER_RESET_SAVED_TERMIOS flag to request that any saved termios state is reset on registration and only set it for drivers that make sure that the minor number is no longer in use. Fixes: 93857edd9829 ("tty: reset termios state on device registration") Reported-by: Chengfeng Ye Link: https://lore.kernel.org/20260926184154.3017929-1-nicoyip.dev@gmail.com Cc: stable@kernel.org # 4.12 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260930131845.1809256-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman [ sashal: adapted the new flag to Greybus’s separate flags assignment and existing macro-based TTY flag definitions. ] Signed-off-by: Sasha Levin commit 96918ca25ff467c25675478fc79393df4ae9d74c Author: Jiazi Liu Date: Mon Oct 5 12:18:25 2026 -0400 usb: dwc3: gadget: fix IRQ storm on invalid event buffer count [ Upstream commit 1ff77cbefe5a653ea12874c213ea4bd0d72c1067 ] When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") returns IRQ_NONE without writing back GEVNTCOUNT. Since the DWC3 interrupt is level-triggered, the uncleared IRQ source keeps the line asserted, causing a tight IRQ storm that accumulates 99,900 unhandled interrupts and triggers spurious.c:184 BUG -> kernel panic. The resulting call stack: __report_bad_irq+0xac/0xc8 note_interrupt+0x340/0x468 handle_irq_event+0xac/0xc0 handle_fasteoi_irq+0x120/0x228 gic_handle_irq+0x68/0x108 ... kernel BUG at kernel/irq/spurious.c:184 To reproduce, write a bogus value exceeding the event buffer length directly to the GEVNTCOUNT register: devmem 4 0x1004 Write the bogus count back to GEVNTCOUNT to clear the IRQ source, consistent with the stale event clearing pattern in dwc3_event_buffers_setup(), and schedule error recovery to reinitialize the controller. Fixes: 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") Cc: stable Suggested-by: Thinh Nguyen Signed-off-by: Jiazi Liu Link: https://patch.msgid.link/20260915110637.17658-1-jiazi.liu1984@gmail.com Acked-by: Thinh Nguyen Signed-off-by: Greg Kroah-Hartman [ sashal: Adjusted gadget initialization context for kzalloc() instead of kzalloc_obj(), and changed dwc3_writel() to pass dwc->regs instead of dwc. ] Signed-off-by: Sasha Levin commit 5d31db7d8c4312d376d1e0ebe0c9c55a6b851d77 Author: Timur Kristóf Date: Mon Oct 5 09:55:39 2026 -0400 drm/amd/display: Fix fast updates on DCE 8.1 [ Upstream commit 687d31ea9ac76b299817060fa1e5582d6c752ae0 ] DCE8 should use legacy fast updates. This was already set for DCE 8.0 and 8.3, but it seems that DCE 8.1 (found in Kaveri chips) was forgotten. This fix should be backported to all kernel versions that have "Refactor fast update to use new HWSS build sequence", but this patch won't apply cleanly to older kernels due to another refactor in "Remove dc param from check_update". Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Fixes: 9ec11bb842b6 ("drm/amd/display: Remove dc param from check_update") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 57605379559e3b5044c8274a1010ec658e5e73af) Cc: stable@vger.kernel.org [ sashal: Omitted the `dc->check_config` assignment because `enable_legacy_fast_update` remains in `dc->debug`. ] Signed-off-by: Sasha Levin commit fd4ed50c134fd9f2334b8b29d117f3af5fe250e9 Author: Andrey Albershteyn Date: Tue Oct 6 23:37:25 2026 +0200 fs,fsverity: remove check for fsverity being enabled in setattr_prepare() commit d2f96bcb89d36d488a10e3bcf819b98536968286 upstream. The check that fs-verity is available in the kernel is not necessary here. Filesystems could have fsverity files even without fs-verity enabled. In that case, truncate on fsverity file will succeed, what this check is trying to prevent. Fixes: e9734653c523 ("fs,fsverity: reject size changes on fsverity files in setattr_prepare") Cc: stable@vger.kernel.org Signed-off-by: Andrey Albershteyn Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260727094352.1734826-1-aalbersh@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit cc99c58f735bc55e6321f1f575ea218da91dcc4c Author: Christoph Hellwig Date: Tue Oct 6 23:37:24 2026 +0200 fs,fsverity: reject size changes on fsverity files in setattr_prepare commit e9734653c523c744f03333ece6ae7a315187f05c upstream. Add the check to reject truncates of fsverity files directly to setattr_prepare instead of requiring the file system to handle it. Besides removing boilerplate code, this also fixes the complete lack of such check in btrfs. Fixes: 146054090b08 ("btrfs: initial fsverity support") Signed-off-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: "Darrick J. Wong" Link: https://lore.kernel.org/r/20260128152630.627409-2-hch@lst.de Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 236a17caebcff31f75bec5ff4136bde2de944e40 Author: Josef Bacik Date: Wed Oct 7 17:55:40 2026 +0000 xen/netfront: drop RX packets with a short Ethernet header commit 089e58805c452e52179482b1025a8e309a57f801 upstream. handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored. Fixes: 0d160211965b ("xen: add virtual network device driver") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9b76a412c8e02336ecd0b492a8225b4b23facdb2 Author: Gilberto Conde Date: Mon Sep 21 10:34:26 2026 +0100 net: usb: qmi_wwan: add Quectel EG120K-EA commit 0f2fd31f63c65c409bd336af3a42d478a9207c1f upstream. Add support for the Quectel EG120K-EA LTE Cat.12 module (USB ID 2c7c:030b). Its QMI interface (interface 4) uses class/subclass/protocol ff/ff/ff like the other recent Quectel modules, so match it the same way. The product ID is shared with the EM060K, which the option driver already knows and uses to claim the serial interfaces. Without a qmi_wwan entry the data interface is left unbound. Tested on a GL.iNet GL-X2000, where the module is soldered down and enumerates at SuperSpeed: cdc-wdm0 and wwan0 appear and ModemManager brings up a data session. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=030b Rev= 5.04 S: Manufacturer=Quectel S: Product=EG120K-EA S: SerialNumber=45546267 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#=12 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by: Gilberto Conde Link: https://patch.msgid.link/20260921093426.2870266-1-gilbertorconde@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bc25f08f628cde749dbbd6a338e54cdba174502f Author: David Howells Date: Tue Dec 2 16:24:53 2025 +0000 cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1 commit 9d85ac939d52e93d80efb01a299c6f0bedb30487 upstream. If a DIO read or an unbuffered read request extends beyond the EOF, the server will return a short read and a status code indicating that EOF was hit, which gets translated to -ENODATA. Note that the client does not cap the request at i_size, but asks for the amount requested in case there's a race on the server with a third party. Now, on the client side, the request will get split into multiple subrequests if rsize is smaller than the full request size. A subrequest that starts before or at the EOF and returns short data up to the EOF will be correctly handled, with the NETFS_SREQ_HIT_EOF flag being set, indicating to netfslib that we can't read more. If a subrequest, however, starts after the EOF and not at it, HIT_EOF will not be flagged, its error will be set to -ENODATA and it will be abandoned. This will cause the request as a whole to fail with -ENODATA. Fix this by setting NETFS_SREQ_HIT_EOF on any subrequest that lies beyond the EOF marker. This can be reproduced by mounting with "cache=none,sign,vers=1.0" and doing a read of a file that's significantly bigger than the size of the file (e.g. attempting to read 64KiB from a 16KiB file). Fixes: a68c74865f51 ("cifs: Fix SMB1 readv/writev callback in the same way as SMB2/3") Signed-off-by: David Howells Reviewed-by: Paulo Alcantara (Red Hat) cc: Shyam Prasad N cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French [Mikhail Mirkin: Adopted for 6.12] Signed-off-by: Mikhail Mirkin Signed-off-by: Greg Kroah-Hartman commit 3b8386331e5a6648208c4b8cc2e8562fad609be3 Author: Marc Zyngier Date: Tue Sep 29 10:35:47 2026 +0100 KVM: arm64: vgic-its: Fix MOVALL handling of source redistributor commit 751f4641560be8568dcc5af400c0e55a283abf51 upstream. The MOVALL command moves the pending state of all LPIs targeting a given redistributor to another one. However, we seem to have lost the filtering on the source RD, which means we move all LPIs to the target. Not quite what the spec mandates. Hack update_affinity() to take an optional source vcpu that is used as a filter when non-NULL, restoring the filtering that was performed by vgic_copy_lpi_list() back in the days. Fixes: 11f4f8f3e6e06 ("KVM: arm64: vgic-its: Walk LPI xarray in vgic_its_cmd_handle_movall()") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929093548.3598547-7-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 9ead78725c4faf9044516fb764b692dc1bd37f99 Author: Baolin Wang Date: Sun Oct 4 06:17:57 2026 -0400 mm: shmem: ignore sysfs configs for shmem forced collapse [ Upstream commit 72c3d682c165b836b54a3d07a01f72e39c47022c ] According to Documentation/mm/transhuge.rst, MADV_COLLAPSE is expected to ignore any THP or mTHP interface settings. However, after commit 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem"), performing MADV_COLLAPSE on shmem will depend on /sys/.../hugepages-2048kB/shmem_enabled being set to "inherit" (although that is the default), which can cause MADV_COLLAPSE to fail unexpectedly. This could cause a userspace-visible performance regression. Fix this by returning the result of shmem_huge_global_enabled() directly when MADV_COLLAPSE is requested, allowing PMD-order collapse while ignoring shmem THP/mTHP settings. Link: https://lore.kernel.org/063f655b4d6c4234f3aa27ed6ecab10283ecb880.1789351825.git.baolin.wang@linux.alibaba.com Fixes: 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem") Signed-off-by: Baolin Wang Signed-off-by: Andrew Morton Reported-by: Kiryl Shutsemau (Meta) Closes: https://lore.kernel.org/all/20260908125105.1510704-7-kirill@shutemov.name/ Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Zi Yan Reviewed-by: Lance Yang Reviewed-by: Barry Song Acked-by: Qi Zheng Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Cc: Dev Jain Cc: Hugh Dickins Cc: Liam R. Howlett Cc: Ryan Roberts Cc: [ sashal: Kept the shmem_huge_global_enabled() call without upstream’s extra vma argument. ] Signed-off-by: Sasha Levin commit 59295a20a161a5effc204fa23a54494dd2633d53 Author: Baolin Wang Date: Sun Oct 4 06:17:56 2026 -0400 mm: shmem: change shmem_huge_global_enabled() to return huge order bitmap [ Upstream commit 736bbc68255fd451d26353a255f15ad347c26132 ] Change the shmem_huge_global_enabled() to return the suitable huge order bitmap, and return 0 if huge pages are not allowed. This is a preparation for supporting various huge orders allocation of tmpfs in the following patches. No functional changes. Link: https://lkml.kernel.org/r/9dce1cfad3e9c1587cf1a0ea782ddbebd0e92984.1732779148.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Acked-by: David Hildenbrand Cc: Barry Song Cc: Daniel Gomez Cc: Hugh Dickins Cc: Kefeng Wang Cc: Lance Yang Cc: Matthew Wilcox Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: 72c3d682c165 ("mm: shmem: ignore sysfs configs for shmem forced collapse") Signed-off-by: Sasha Levin commit 3e8de03db9edb6140c33a7a16d0321f83ee1b4d0 Author: Baolin Wang Date: Sun Oct 4 06:17:55 2026 -0400 mm: factor out the order calculation into a new helper [ Upstream commit da243c5479add600bdd58c910c9fae3355b4f026 ] Patch series "Support large folios for tmpfs", v3. Traditionally, tmpfs only supported PMD-sized large folios. However nowadays with other file systems supporting any sized large folios, and extending anonymous to support mTHP, we should not restrict tmpfs to allocating only PMD-sized large folios, making it more special. Instead, we should allow tmpfs can allocate any sized large folios. Considering that tmpfs already has the 'huge=' option to control the PMD-sized large folios allocation, we can extend the 'huge=' option to allow any sized large folios. The semantics of the 'huge=' mount option are: huge=never: no any sized large folios huge=always: any sized large folios huge=within_size: like 'always' but respect the i_size huge=advise: like 'always' if requested with madvise() Note: for tmpfs mmap() faults, due to the lack of a write size hint, still allocate the PMD-sized large folios if huge=always/within_size/advise is set. Moreover, the 'deny' and 'force' testing options controlled by '/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same semantics. The 'deny' can disable any sized large folios for tmpfs, while the 'force' can enable PMD sized large folios for tmpfs. This patch (of 6): Factor out the order calculation into a new helper, which can be reused by shmem in the following patch. Link: https://lkml.kernel.org/r/cover.1732779148.git.baolin.wang@linux.alibaba.com Link: https://lkml.kernel.org/r/5505f9ea50942820c1924d1803bfdd3a524e54f6.1732779148.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Suggested-by: Matthew Wilcox Reviewed-by: Barry Song Reviewed-by: David Hildenbrand Reviewed-by: Daniel Gomez Cc: Hugh Dickins Cc: Kefeng Wang Cc: Lance Yang Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: 72c3d682c165 ("mm: shmem: ignore sysfs configs for shmem forced collapse") Signed-off-by: Sasha Levin commit 7ac67b0e423ffd3d6b4b6d8047080b8cfec672de Author: Kefeng Wang Date: Sun Oct 4 06:17:54 2026 -0400 mm: shmem: remove __shmem_huge_global_enabled() [ Upstream commit 4a9a27fdf7bfd29013491aea45e3512988cc5876 ] Remove __shmem_huge_global_enabled() since it as only one caller, and remove repeated check of VM_NOHUGEPAGE/MMF_DISABLE_THP as they are checked in shmem_allowable_huge_orders(), also remove unnecessary vma parameter. Link: https://lkml.kernel.org/r/20241017141457.1169092-2-wangkefeng.wang@huawei.com Signed-off-by: Kefeng Wang Reviewed-by: Baolin Wang Acked-by: David Hildenbrand Cc: Barry Song Cc: Hugh Dickins Cc: Matthew Wilcox Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: 72c3d682c165 ("mm: shmem: ignore sysfs configs for shmem forced collapse") Signed-off-by: Sasha Levin commit f8f7d86b3537e885ee620898a38b749fba8a8456 Author: Paulo Alcantara Date: Sun Oct 4 05:36:42 2026 -0400 netfs: clear post-EOF pagecache when extending a file via write [ Upstream commit 69bf14300b50631e7c2271289d347bbd1b19a06c ] Fix netfs to erase the contents of a hole created after the EOF by an ordinary write if dirty data has been previously left there by writes through an mmapped region. Neither the buffered nor the unbuffered/DIO write path clears that stale pagecache. Zero the tail of the folio straddling the EOF before an extending write. That is the only folio that can hold data written past the EOF through an mmap, as pages wholly beyond the EOF can't be faulted in. The folio is zeroed rather than dropped so a concurrent extending write can't lose data. Both write paths downgrade the i_rwsem to shared, so extending writes can run concurrently and the i_size read by the caller may be stale by the time the folio is locked. Re-read i_size under the folio lock and clamp the zeroed range up to it, so a racing write that already put data into the folio isn't clobbered. Wait for any writeback on the folio to finish before zeroing it so that the pagecache isn't modified while it may still be read by the transport during transmission. Honour IOCB_NOWAIT by returning -EAGAIN rather than blocking on the folio lock, on writeback, or in folio_mkclean()'s rmap walk when the folio is mapped. truncate_pagecache() can't be used here: it must be called with the i_rwsem held exclusively, but these write paths only hold it shared, and it would block unconditionally, breaking IOCB_NOWAIT. Callers that hold i_rwsem exclusively for the whole resize (truncate, setattr, fallocate, clone) exclude any genuine concurrent buffered writer, so staleness can instead be decided from the folio's dirty state, as pagecache_isize_extended() already does for filesystems that serialise writes against truncate/setattr via a single i_rwsem. Export netfs_clear_stale_post_isize() helper to handle such case. The helper is required by the CIFS client to fix generic/363. Closes: https://sashiko.dev/#/patchset/20260921230755.1133425-1-pc%40manguebit.org Fixes: 938e13a73b24 ("netfs: Implement buffered write API") Fixes: 153a9961b551 ("netfs: Implement unbuffered/DIO write support") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced `uoff_t` with `unsigned long long` and placed the new functions, prototype and docs section at different spots because the surrounding context differs. ] Signed-off-by: Sasha Levin commit dcb8f6a79c3360a440c399d85df465a6e59351f1 Author: Xuanqiang Luo Date: Sun Oct 4 05:23:06 2026 -0400 pfcp: fix socket lifetime on netdevice registration failure [ Upstream commit 0f17d2e3dd9cda3ee6d94033d5e5489af168920d ] pfcp_newlink() creates the UDP socket before register_netdevice(). If registration fails after pfcp_dev_init() succeeds, the core calls pfcp_dev_uninit(), which releases the socket and clears pfcp->sk. The newlink error path then releases it again, causing a NULL pointer dereference. This was observed with failslab fault injection: FAULT_INJECTION: forcing a failure. kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net) BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50 Read of size 8 at addr 0000000000000120 by task ip/1037 Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x468/0x5cc kasan_report+0xa4/0xf0 __asan_load8+0x7c/0xd0 udp_tunnel_sock_release+0x1c/0x50 pfcp_newlink+0x128/0x184 rtnl_newlink+0x848/0xe44 rtnetlink_rcv_msg+0x468/0x514 netlink_rcv_skb+0xc0/0x1f0 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x558 netlink_sendmsg+0x2b8/0x584 ... Return from pfcp_del_sock() if pfcp->sk is NULL. Fixes: 76c8764ef36a5 ("pfcp: add PFCP module") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260924055252.33488-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni [ sashal: Adapted the socket null check from pfcp->sk to pfcp->sock. ] Signed-off-by: Sasha Levin commit 2261f857ef4e0d21eb1a8b47b06640cf7ab16d3e Author: Paolo Abeni Date: Mon Oct 5 19:52:27 2026 +0200 mptcp: prevent race between disconnect() and rtx [ Upstream commit 85c580b0d8590520ae00a15c29e9fb9c99427a3e ] Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation. Cc: stable@vger.kernel.org Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-6-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski [ No conflicts, but reset msk->timer_ival to TCP_RTO_MIN: in this kernel version, icsk->icsk_rto_min is not initialised, because this version doesn't contain commit ea4eb2adb0d3 ("mptcp: honour configured min/max RTO in retransmit paths"). Use TCP_RTO_MIN, similar to how msk->timer_ival is reset in __mptcp_init_sock() in this version. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Sasha Levin commit f0ab9e495dcb0c0972b5c0e11aee16fcccc4343e Author: Mehmet Fide Date: Tue Sep 1 09:39:07 2026 +0200 mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages [ Upstream commit 68fe2faf5c69d0e21f94cd695d28f0ba677d484f ] When the ECC engine fails to decode a page, the driver re-reads the OOB area with the engine bypassed, but runs the erased-page check for the data area on the buffer left in the controller SRAM by the failed transfer. That buffer does not hold what is on the flash: the failing engine writes a bogus single-bit "correction" into it. In the 60-byte ECC mode the all-0xff content of an erased page always decodes to the same error location, so every erased page shows one stale zero bit at data offset 0x5FD, which the erased-page check then reports as a corrected bitflip. Edward Karpicz discovered this behaviour and identified the offset on a Colibri VF61; the analysis and the fix build on his finding. Measured with an instrumented driver on a Colibri VF50 (MX30LF1G18AC, 32-bit ECC): reading a 126 MiB partition with nanddump increased the corrected counter by 18035, exactly one per erased page, while raw reads of the same pages return clean 0xff. A v4.4 kernel on the VF61 (MX30LF4G28AC) accumulates the same false counts, so the behaviour follows the controller rather than the chip or the driver generation. Neither the Vybrid reference manual nor the published mask set errata (VFXXX_2N02G) document it. The 45-byte ECC mode is not affected. Restoring the known byte is not enough: on pages that fail to decode with content other than all-0xff the engine writes its correction wherever the syndrome points (measured at a different offset on such a page), so the check has to run on what the flash holds. Re-read the data area with the ECC engine bypassed, exactly as already done for the OOB area. The corrected counter then stays at zero on both boards. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 1485a3dd97ab1af2605243cabe6b604546d46dd1 Author: Yi Yang Date: Sun Oct 4 13:38:59 2026 -0400 vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF [ Upstream commit 226bd5603371cd9f6642cbb9e9a677f445de3530 ] The reload of 'vc' added by commit 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") sits after the 'if (ret)' block, so the copy-failure break path exits the loop without reloading vc. If the vc was kfree()'d via vc_port_destruct during the unlocked copy_from_user() window, the post-loop 'if (written && vc) vcs_scr_updated(vc)' is reached with a stale non-NULL vc. The '&& vc' guard from commit a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") only handles the NULL case, not this stale-non-NULL case; vcs_notifier() then reads param->vc->vc_num from freed memory: BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0 Read of size 2 at addr ffff888007149190 Call Trace: vcs_notifier+0x7c/0xd0 atomic_notifier_call_chain+0x70/0xa0 vcs_scr_updated+0x77/0xa0 vcs_write+0x71b/0x7e0 Allocated by task: vc_allocate -> con_install -> tty_open Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE -> vc_port_destruct) Move the reload to immediately after console_lock(), before 'if (ret)', so every break path below passes a fresh vc to the post-loop vcs_scr_updated(). Fixes: a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") Cc: stable@kernel.org Signed-off-by: Yi Yang Link: https://patch.msgid.link/20260901113131.2760010-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3407fab05b1968a364cda1a980762e7eb2c77280 Author: Jiri Slaby (SUSE) Date: Sun Oct 4 13:38:58 2026 -0400 tty/vt: use guard()s [ Upstream commit e730c373b6ff16a177e132859bf6ea4dbb15105f ] Having all the new guards, use them in the vt code. This improves readability, makes error handling easier, and marks locked portions of code explicit. A local free_page_ptr __free guard is introduced for __get_free_page/free_page (with proper casts). This could be made public in include/. But I am not sure if there are more possible users, so keeping completely private here. Signed-off-by: "Jiri Slaby (SUSE)" Link: https://lore.kernel.org/r/20250814072456.182853-16-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Use scope-based console locking and buffer cleanup in vcs_write() so error paths can return directly while releasing both resources. Limit the conversion to the function needed by the follow-up console pointer reload fix. Omit the other guard conversions, including the selection changes whose context assumes bracketed-paste support. Allocate the page-sized copy buffer with kmalloc() and reuse the existing kfree cleanup guard instead of introducing a new cleanup helper. Declare the buffer before the console guard so the console is unlocked before the buffer is freed, preserving the original cleanup order. [ sashal: REDUCED BACKPORT of e730c373b6ff: carries 29/414 upstream changed lines; not carried: drivers/tty/vt/consolemap.c:con_set_trans_old(), drivers/tty/vt/consolemap.c:con_get_trans_old(), drivers/tty/vt/consolemap.c:con_set_trans_new(), drivers/tty/vt/consolemap.c:con_get_trans_new(), drivers/tty/vt/consolemap.c:con_clear_unimap(), drivers/tty/vt/selection.c:sel_loadlut(), drivers/tty/vt/selection.c:set_selection_kernel(), drivers/tty/vt/selection.c:paste_selection(), +28 more ] Stable-dep-of: 226bd5603371 ("vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF") Signed-off-by: Sasha Levin commit 598377d10b2936f213889cf6ab1c9fc50f4e6c5b Author: Jiri Slaby (SUSE) Date: Sun Oct 4 13:38:57 2026 -0400 console: introduce console_lock guard()s [ Upstream commit 4847d1187402a5027d9a04393f12d52a5a1d7f98 ] Having this, guards like these work: guard(console_lock)(); or scoped_guard(console_lock) { ... } See e.g. "vc_screen: use guard()s" later in this series. Signed-off-by: "Jiri Slaby (SUSE)" Link: https://lore.kernel.org/r/20250814072456.182853-2-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 226bd5603371 ("vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF") Signed-off-by: Sasha Levin commit 203ffe648948ca3c2f55b21118945a7a6d0884aa Author: Asad Kamal Date: Tue Jun 23 00:25:04 2026 +0800 drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read [ Upstream commit 5d3cc8e388464f485d0944b87b8f9426e637d082 ] Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table. Fixes: c82baa281843 ("drm/amd/powerplay: add Tonga dpm support (v3)") Fixes: 0d2c7569e196 ("drm/amdgpu: add new atomfirmware based helpers for powerplay") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ee70d690b5544b736706a9a5796aafb634013f54 Author: Chuck Lever Date: Wed May 27 11:00:13 2026 -0400 svcrdma: Use svc_xprt_put to free listener on create failure [ Upstream commit e346ef7bcb137f50c49f969330ab7dcf64ea1654 ] svc_rdma_create() calls kfree(cma_xprt) when svc_rdma_create_listen_id() fails. svc_xprt_init() has already acquired a net namespace reference via get_net_track(); kfree bypasses svc_xprt_free() which releases it. Replace the kfree() with svc_xprt_put() so the kref_init birth reference drops to zero and svc_xprt_free() dispatches svc_rdma_free() to clean up properly. sc_cm_id is still NULL at that point; the preceding patch added the necessary NULL guard in svc_rdma_free(). svc_xprt_free() also drops the module reference via module_put(), but the caller _svc_xprt_create() does the same on xpo_create failure, double-putting the single try_module_get() it acquired. Take a compensating __module_get() before the svc_xprt_put() to keep the count balanced, matching the convention in svc_rdma_accept()'s error path. Fixes: 4fb8518bdac8 ("sunrpc: Tag svc_xprt with net") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-3-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2c3a87ad3d3935c43d465cd2465db9020f9e898f Author: Fuad Tabba Date: Fri Aug 7 11:40:59 2026 +0100 KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save [ Upstream commit c6c156d931c33b92362383cf76f6d6e1291dcbfe ] MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have. Fixes: eff484e0298da ("KVM: arm64: vgic-its: ITT save and restore") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260807104102.2410744-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin commit 2ec34dc7094b14149ce091c77aff43a45d255518 Author: Aditya Dutt Date: Tue Apr 1 20:59:16 2025 +0530 jfs: fix array-index-out-of-bounds read in add_missing_indices [ Upstream commit 5dff41a86377563f7a2b968aae00d25b4ceb37c9 ] stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error. Reported-by: syzbot+b974bd41515f770c608b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com./bug?extid=b974bd41515f770c608b Signed-off-by: Aditya Dutt Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 92803b826e40e49a5e8a6e208f4b4574e9d19426 Author: Eric Dumazet Date: Mon Oct 5 16:06:51 2026 +0200 ipv6: use RCU in ip6_output() [ Upstream commit 11709573cc4e48dc34c80fc7ab9ce5b159e29695 ] Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF. We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2(). Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit cf513df1a2c75566cdc802d9da47f62e8d6cfd18 Author: Fan Wu Date: Thu Aug 6 14:25:02 2026 +0000 iio: trigger: cancel reenable_work before freeing trigger commit 2a57b9246cecd5dd797a42eb310d6c8816f26d9e upstream. iio_trigger_notify_done_atomic() defers ->reenable() into trig->reenable_work on the system workqueue, and the worker dereferences the owning trigger through container_of(). Nothing cancels this work before iio_trig_release() frees the trigger, so a worker armed by the last in-flight IRQ can outlive the free and touch freed memory. Cancel it at the top of iio_trig_release(), which every free path reaches through the device core's final put_device(). Found by an in-house static analysis tool. Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 59a7d19d6dd00287ba56ce3de6ac4b5f6f073b3d Author: Salah Triki Date: Mon Aug 24 05:29:07 2026 +0100 iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler commit 7d38af8f20239a66e90de7632a79c9425256c574 upstream. The threaded IRQ handler contained multiple issues in handling interrupt events and clearing status flags: 1. ISR bit check: The handler incorrectly checked the Interrupt Status Register (VCNL_ISR) against VCNL_ICR_THRES_EN (BIT(1)), which is a bitmask meant for the Control Register (VCNL_PS_ICR). In VCNL_ISR, BIT(1) corresponds only to low-threshold interrupts. A high-threshold interrupt (VCNL_INT_TH_HI, BIT(0)) on its own was completely ignored and returned IRQ_NONE. 2. Event direction & channel index: The handler unconditionally pushed a RISING event code on channel index 1. The driver only registers a single proximity channel (index 0), and low-threshold interrupts should be reported with IIO_EV_DIR_FALLING. 3. ISR clearing: The write-back to acknowledge the interrupt only preserved BIT(1) instead of masking against both valid status bits. Fix this by checking both VCNL_INT_TH_HI and VCNL_INT_TH_LOW bits in VCNL_ISR, pushing separate IIO events with the correct direction and channel index (0), and properly clearing handled status bits. Fixes: 3363fbbe19e5 ("iio: proximity: vcnl3020: add periodic mode") Signed-off-by: Salah Triki Reviewed-by: Ivan Mikhaylov Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 977b92dc9024d94d210deaebf4b0ff8cafa68de9 Author: Zhang Jie Date: Tue Aug 18 15:28:03 2026 +0800 iio: proximity: sx9324: Correct proximity channel resolution commit fbf33cb18334e7cab1ed4ad2e9a98a1299ad874c upstream. The proximity channels were previously defined with 12 realbits. However, PROXDIFF is read from RegDiffMsb (0x65) and RegDiffLsb (0x66). The SX9324 datasheet assigns bits 7:0 of each register to PROXDIFF and documents it as a signed two's-complement value (Revision 3, Section 8, Table 8, page 43). In contrast, RegOffsetMsb explicitly marks bits 7:6 as reserved. Thus, PROXDIFF is a 16-bit signed value. With realbits = 12, sx_common_read_proximity() uses bit 11 as the sign bit in sign_extend32(), causing samples outside the 12-bit signed range to wrap into the [-2048, 2047] range. Correct the realbits value to 16 to accurately reflect the hardware. Tested on an SX9324-based device: a phase 0 DIFF readback of 0x7fff was reported as -1 before this change and as 32767 afterward. Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Jie Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 06fa13c53442257b94ea1519555ceddaaea57e0d Author: Cong Nguyen Date: Fri Aug 28 17:59:09 2026 +0700 iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure commit 4daa9ca557b4b98ae1ad38a6d1deaa3e31eb8edf upstream. pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer, which only calls iio_triggered_buffer_cleanup() -- it does not undo the iio_device_register() that already succeeded a few lines above. probe() then returns the error, the devm-managed indio_dev is freed, but the iio core still has it registered: the sysfs/chardev nodes stay live and point at freed memory. Add an error_unreg_dev label that unregisters the iio device before falling through to the existing buffer cleanup, mirroring the teardown order already used in lidar_remove(). Fixes: 4ac4e086fd8c ("iio: pulsedlight-lidar-lite: add runtime PM") Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 32d48edc75ed44d96055b9cc97f094382c854e3e Author: Salah Triki Date: Thu Sep 17 14:00:52 2026 +0100 iio: proximity: isl29501: Fix return type of isl29501_register_write commit e8dd273d199f5bbe295a8e3d8b777c5505b6b2e1 upstream. isl29501_register_write() was returning a u32 instead of an int. Since the function returns negative error codes (such as -ERANGE or return values from i2c_smbus_write_byte_data()), returning an unsigned integer type prevents callers from correctly checking for negative error conditions. Fix this by changing the function return type from u32 to int. This was found through manual code review. Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4a9b9f2d4e26589afd0ac099c8e5593170dd5ac7 Author: Laxman Acharya Padhya Date: Sun Aug 2 01:22:00 2026 +0545 iio: proximity: aw96103: validate firmware data length commit 1a7c522a35477d70320bd64aba8e9de0c1058c6f upstream. The firmware parser reads a length from the binary header and then uses it to walk six-byte register/value entries. A truncated firmware image can make the parser read beyond the copied firmware buffer. A value smaller than the four-byte count field also underflows, producing a very large length. Read the little-endian field with get_unaligned_le32(), as previously proposed by David Lechner. Validate the header size, reject an underflowed length, ensure the resulting payload is contained in the firmware image, and require it to contain whole register/value entries. Fixes: 07b241262dca ("iio: proximity: aw96103: Add support for aw96103/aw96105 proximity sensor") Link: https://lore.kernel.org/r/20260314-iio-proximity-aw96103-fix-firmware-read-v1-1-c74fe9ccd82b@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9db6684fab228edd3b8861a172ccbce3236f027a Author: Hui Su Date: Tue Aug 11 10:52:53 2026 +0800 iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup commit 56c423b233b214182c58c99861899327b45b0d6c upstream. The sampling frequency tables store each frequency as an integer part and a fractional part in micro units. num_sampling_freq_avail is initialized to the number of flattened integer elements because read_avail() returns the table as a flat array. bmp280_write_sampling_frequency(), however, indexes the same table as a two-dimensional array and uses num_sampling_freq_avail as the number of rows. Convert the flattened element count back to the number of rows before iterating over the table. Fixes: 10b40ffba2f9 ("iio: pressure: bmp280: Add more tunable config parameters for BMP380") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a36814b9fe00970116d30c3143d81e7425c4d334 Author: Fan Wu Date: Thu Aug 6 13:29:23 2026 +0000 iio: light: gp2ap020a00f: drain irq_work after free_irq commit 63213927b141085b6c8719b8037dab3074b7e0fe upstream. The threaded IRQ handler queues data->work through irq_work_queue() so the trigger is polled from a per-CPU context. free_irq() does not flush an irq_work the handler already queued, so after gp2ap020a00f_remove() returns that work may still run and call iio_trigger_poll() on data->trig, which the devm cleanup has already freed, causing a use-after-free. Add irq_work_sync(&data->work) after free_irq() in remove() and in the probe error path, mirroring commit 78601726d4a5 ("iio: trigger: sysfs: fix use-after-free on remove"). Found by an in-house static analysis tool, confirmed by manual review. Fixes: bf29fbeaa13d ("iio: gp2ap020a00f: Add a driver for the device") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b7e507c6da8875da93b4130c8185e82a9dfd565c Author: Arka Mondal Date: Sun Aug 16 03:27:24 2026 +0900 iio: imu: adis16480: fix unprotected debugfs reads commit e1dea54496f90a62318cf4eeaa1e9ef8316e92b6 upstream. The firmware_revision and firmware_date file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it. Use debugfs_create_file() instead. Fixes: 9bf94f836e32 ("imu:adis16480: fix debugfs_simple_attr.cocci warnings") Signed-off-by: Arka Mondal Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e9b4c00f775a915b759b08bfe2c5e806a8301a59 Author: Arka Mondal Date: Sun Aug 16 03:27:25 2026 +0900 iio: imu: adis16400: fix unprotected debugfs reads commit d94787287a113a1326211647d5e0deed1e9de105 upstream. adis16400_serial_number_fops is open coded and never calls debugfs_file_get(), so debugfs_remove_recursive() does not wait for a read in progress and unbind frees the iio_dev underneath it. Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but moved all three files to debugfs_create_file_unsafe(). serial_number prints three registers as "%.4x-%.4x-%.4x" and DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be converted without changing what the file returns. adis16475 and adis16550 already use debugfs_create_file() for their open coded files. Use it here too. Fixes: ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") Signed-off-by: Arka Mondal Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit eeb23ba97bd8016e815ef70300b8d34a0a316b90 Author: Marco Chen Date: Sat Aug 8 15:54:50 2026 -0400 iio: health: max30102: fix NULL dereference in interrupt handler commit f0ea4824deebf21dacfbe397c4b0a5fd3e745a8d upstream. The interrupt is requested in max30102_probe() and stays enabled for the lifetime of the device, but indio_dev->active_scan_mask is only valid while a buffer is enabled. When an interrupt arrives while no buffer is enabled, the handler dereferences the NULL active_scan_mask: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __bitmap_weight+0x64/0x98 (P) max30102_interrupt_handler+0x48/0x160 [max30102] Call max30102_fifo_count() at the top of the handler and return early unless it reports a FIFO sample is ready. Because FIFO_RDY is the only interrupt source enabled in max30102_chip_init(), an invocation of max30102_interrupt_handler() without the FIFO_RDY interrupt status bit set carries no data to read and can return before touching active_scan_mask. A negative return from max30102_fifo_count() indicates a failed interrupt status read and is treated the same way. Fixes: 90579b69e94b ("iio: health: max30102: Add MAX30105 support") Suggested-by: Jonathan Cameron Signed-off-by: Marco Chen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d5b0b62e26d7d30e0e16e2d695f2161f7e92a5a5 Author: Arka Mondal Date: Sun Aug 16 03:27:26 2026 +0900 iio: gyro: adis16136: fix unprotected debugfs reads commit 2b498df75d6c29aa3e760127ae0f0003df598b53 upstream. The serial_number file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it. Use debugfs_create_file() instead. Fixes: 9aaea09b4cbd ("gyro:adis16136: fix debugfs_simple_attr.cocci warnings") Signed-off-by: Arka Mondal Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 43a5cbf2cd5b6ed635803472c6fcfef9595d7508 Author: Salah Triki Date: Wed Aug 19 18:51:19 2026 +0100 iio: frequency: admv1013: fix wrong channel field used in admv1013_read_raw() commit 2093236e886ad9446ec3285ba520e024dd1464e1 upstream. admv1013_read_raw() switches on chan->channel instead of chan->channel2 when handling IIO_CHAN_INFO_CALIBBIAS. The channel field only ever holds 0 or 1 (see ADMV1013_CHAN_CALIB()), while the IIO_MOD_I / IIO_MOD_Q modifiers are stored in channel2. As a result, the switch always falls through to the default case and calibbias reads always fail with -EINVAL, even though the corresponding admv1013_write_raw() path correctly uses channel2 and works as expected. Fix the read path to switch on chan->channel2, matching the write path and the actual channel_spec definition. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Signed-off-by: Salah Triki Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b5c2f21f645e40c70fda2a4283e6f2a81e5cb9f2 Author: Jonathan Cameron Date: Mon Aug 3 02:22:24 2026 +0100 iio: buffer: Ensure bounce buffer used for unaligned case is zeroed. commit 5330036bc68d23672bfcc16c60c54701ae123083 upstream. iio_push_to_buffers_with_ts_unaligned() leaks uninitialized heap memory to userspace if the data passed in is not a multiple of 8 bytes and the timestamp is enabled. Specify __GFP_ZERO for the devm_krealloc() to ensure any extra space is cleared. Fixes: 95ec3fdf2b79 ("iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260529121005.1470-1-kimjinseob88%40gmail.com Reviewed-by: Andy Shevchenko Reviewed-by: Joshua Crofts Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 89f3852a28fcf7bab599280cb082baa0675536db Author: Jinseob Kim Date: Mon Sep 21 15:24:21 2026 +0900 iio: buffer: serialize buffer teardown with mode claims commit 84bb0fc46ccf6a545b8fdf57cda83770186ed8dd upstream. Buffer-mode claims hold mlock to guarantee that the device remains in buffer mode until the claim is released. Normal buffer updates take info_exist_lock followed by mlock in iio_update_buffers(). However, iio_device_unregister() disables and deactivates all buffers without taking mlock. This can invalidate buffer state, including active_scan_mask, while a buffer-mode claim is held. Take mlock in iio_disable_all_buffers() so that unregister honors the mode-claim lifetime guarantee. The info_exist_lock -> mlock ordering matches iio_update_buffers(). Fixes: 0a8565425afd ("iio: core: introduce iio_device_{claim|release}_buffer_mode() APIs") Suggested-by: Jonathan Cameron Signed-off-by: Jinseob Kim Reviewed-by: Joshua Crofts Reviewed-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7bef5530a6fa9550fb9c7211ffc9394dd6d6b21d Author: Runyu Xiao Date: Wed Aug 19 22:17:51 2026 +0800 iio: admv1013: initialize callback mutex before registering notifier commit baf7e43b7fb5afb777353bf265ddf9d909f72b9f upstream. admv1013_probe() registers a clock notifier whose callback takes st->lock on POST_RATE_CHANGE. Initialize the mutex before devm_clk_notifier_register() so the callback cannot observe an uninitialized lock during probe. Use devm_mutex_init() so the lock lifetime is tied to the device and cleanup stays paired with the rest of the managed probe resources. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a29d385ad7b340c952a3935af2b33488db1eb3a6 Author: Fan Wu Date: Mon Aug 3 08:03:43 2026 +0000 iio: adc: xilinx-xadc: free IRQ before cancelling the unmask worker on unbind commit 0f3f427076240e75ff265e61645627a71ca4918c upstream. The ZYNQ XADC alarm IRQ handler queues zynq_unmask_work via schedule_delayed_work(); that work is cleared by a devm callback. Register the devm callback before devm_request_irq() so the devres LIFO teardown frees the IRQ first, ensuring the handler can no longer queue work by the time the workqueue is cleared. Otherwise the handler could re-arm the work and run it after the xadc structure has been freed. This issue was found by an in-house static analysis tool. Fixes: 2a9685d1a3b7 ("iio: adc: xilinx: use more devres helpers and remove remove()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Reviewed-by: David Lechner Signed-off-by: Fan Wu Reviewed-by: Sai Krishna Potthuri Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8d3c4648e316824f37cca1fa3993ad64b03d6b75 Author: Felix Gu Date: Sun Sep 6 23:58:34 2026 +0800 iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls commit 8b958dd214ad0c003f56549e9e039cb8067dc1a2 upstream. Neither the error path in sun4i_gpadc_probe() nor sun4i_gpadc_remove() ever holds a runtime PM usage count. So the pm_runtime_put() in both places always triggers the "Runtime PM usage count underflow!" warning on every failed probe and every unbind. Drop both calls. Fixes: d1caa9905538 ("iio: adc: add support for Allwinner SoCs ADC") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1bad19e598cd77884d812fd2f88b05c635b5e7ad Author: Felix Gu Date: Sun Sep 6 23:58:35 2026 +0800 iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure commit 2cdc7ef31827db4fbc6283750420639569e1f0e9 upstream. If devm_thermal_of_zone_register() fails, probe returns without unregistering the IIO map array or disabling runtime PM. Jump to err_map to release them. Fixes: b0a242894f11 ("iio: adc: sun4i-gpadc-iio: register in the thermal after registering in pm") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c2f6204a0cbe04b1b5e8d9e95762e526c438e60b Author: Fabrice Gasnier Date: Wed Sep 16 19:18:38 2026 +0200 iio: adc: stm32-adc: fix check on internal channel availability commit 9db3deeb2de485a9d412f0825f9ab4c8e2bccf44 upstream. If an unsupported internal channel like vddgpu is requested, the driver prints a warning but falls through and assigns it a valid int_ch below. This causes a problem later during setup: stm32_adc_int_ch_enable() { ... case STM32_ADC_INT_CH_VDDGPU: stm32_adc_set_bits(adc, adc->cfg->regs->or_vddgpu.reg, adc->cfg->regs->or_vddgpu.mask); ... } Because the register offset is uninitialized (0), this performs a read-modify-write on offset 0, which corresponds to the ISR register. Fix this by returning before a valid int_ch is assigned. Choice is made to keep current driver behavior to warn about the channel name. Fixes: cf0fb80ae167 ("iio: adc: stm32-adc: add stm32mp13 support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260911162602.D323F1F000FF@smtp.kernel.org/ Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b7ac07d0b1a44bf644733298e80fd1f22e2f0cc1 Author: Slavin Liu Date: Sun Sep 13 20:51:07 2026 +0800 iio: adc: pac1934: check ACPI label duplication commit 64c82e7bd9c82b0c9276297df34a3579e8658f55 upstream. A label duplication failure currently reaches the terminating-byte write. Release the ACPI result and abort before accessing the missing label; earlier labels are managed by devres. Detected by static analysis and reviewed with AI-assisted source auditing. Fixes: 0fb528c8255b ("iio: adc: adding support for PAC193x") Assisted-by: LLM Signed-off-by: Slavin Liu Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4940fab799c6bf7e7b58344c1fed854de19d0dcb Author: Salah Triki Date: Wed Aug 19 12:41:01 2026 +0100 iio: accel: sca3000: fix frequency divider condition check commit d380bf5f94a892e546d9a94e8557ad866b043a2a upstream. When setting the sampling frequency, the check for `base_freq / 2` is followed by an independent `if` statement for `base_freq / 4`. If `val` equals `base_freq / 2`, the second check fails and falls through to the `else if (val != base_freq)` branch, returning `-EINVAL` erroneously. Fix this by chaining the checks with `else if`. Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ad690c0c1b9131725619e352cb7c970488cbf436 Author: Jiale Yao Date: Fri Sep 25 22:09:43 2026 +0800 iio: accel: kxcjk-1013: reject duplicate event disable commit dd30c10ff60d2b30386c23bb7c61cc97f2385c97 upstream. The IIO core does not filter duplicate writes to the event enable attribute. kxcjk1013_write_event_config() already ignores repeated enable requests, but a repeated disable request still calls kxcjk1013_set_power_state(data, false), dropping a runtime PM reference that was not acquired for this request. This can underflow the runtime PM usage count and trigger a "Runtime PM usage count underflow" warning. Return early when the requested state already matches ev_enable_state. Fixes: b4b491c0832e ("iio: accel: kxcjk-1013: Support thresholds") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3786ee67658a2c80fef2544e7de2cd329e043cf9 Author: Frank Sorenson Date: Wed Sep 30 15:47:15 2026 -0500 smb: client: split cifsFileInfo bitfields to avoid shared-byte RMW races commit 19465a9aeb664f1d710d0d22c07c31bfb7c85446 upstream. The invalidHandle, swapfile, oplock_break_cancelled, offload, and status_file_deleted fields are stored in the same bitfield byte in struct cifsFileInfo, but are updated in different code paths that may run simultaneously, and are protected by different locks. Since bitfield assignments generate byte-level read-modify-write operations, a modification to one flag can overwrite a concurrent modification to another flag. To avoid these races, convert these flags from a bitfield to separate bool fields. Closes: https://lore.kernel.org/r/7689764e-c0f6-4016-9557-b54cf4a3de4e@redhat.com Fixes: 3bc303c254335 ("cifs: convert oplock breaks to use slow_work facility (try #4)") Fixes: 4e8aea30f7751 ("smb3: enable swap on SMB3 mounts") Fixes: ffceb7640cbfe ("smb: client: do not defer close open handles to deleted files") Fixes: 173217bd73365 ("smb3: retrying on failed server close") Signed-off-by: Frank Sorenson Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit abe9a820b33a5fee324eaba35f0ce12880de152b Author: Paulo Alcantara Date: Sun Sep 20 16:37:41 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via copy range commit 7b473ac7cd6f7e087876d3c67b1bc6df662fb429 upstream. cifs_file_copychunk_range() invalidated the pagecache only for the destination region, so when a copy extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the invalidation at the smaller of the destination offset and the old EOF. filemap_invalidate_inode() writes back before invalidating while i_size is still old, so nothing past the old EOF is flushed to the server. Fixes: 8101d6e112e2 ("cifs: Fix copy offload to flush destination region") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 94949b6b2f2bf0dba2e8786aed0b08cc6bc3a183 Author: Paulo Alcantara Date: Sun Sep 20 16:09:30 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via zero range commit da4fe97fb6c730d9c94a115c7bfa6f98e0d578d0 upstream. smb3_zero_range() removed the pagecache only for the range being zeroed, so when it extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Lower the discard boundary to the smaller of the zero-range offset and the old EOF. Fixes: 72c419d9b073 ("cifs: fix smb3_zero_range so it can expand the file-size when required") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a766a86ff48acee76aeb8e2575771040749e509d Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 9 10:07:37 2026 +0900 thunderbolt: Reject oversized XDomain properties responses commit 80756e263846ab694984e749e8c626897331438f upstream. tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer. The XDomain length field is six bits wide, however, and a malicious peer can set it to 63. After the fixed response fields are subtracted, the driver treats this as 48 data dwords. Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len. If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read. Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length. Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block. Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 0b739501fb3aa3e7768cbfee0d0bb79b1d8f3ab1 Author: Kurt Lieber Date: Thu Sep 24 12:26:37 2026 +0000 thunderbolt: Disable CL states for the Anker Prime TB5 dock commit 395e9f2967a7ac6898026e8f136c369805dc2fd9 upstream. The Anker Prime TB5 dock identifies itself in the DROM as 01ea:83b5. Its router config space is an Intel Barlow Ridge 80G hub (8087:5786). The upstream lane adapter advertises CL0s, CL1, and CL2. With CLx left enabled, TMU uni-directional LowRes setup fails with -ENOTCONN, the USB3 and DisplayPort tunnels are aborted, and the router reconnects in a loop. Loading thunderbolt with clx=0 keeps the link up on this machine. Match the DROM id together with the Barlow Ridge hub id and disable CL states for this dock only. QUIRK_NO_CLX takes the same early-out as the module parameter, without disabling CLx for every other router. Closes: https://lore.kernel.org/linux-usb/SJ0PR15MB4696D491504DB667AA8E0617A3812@SJ0PR15MB4696.namprd15.prod.outlook.com/ Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Kurt Lieber Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 71b3c517e02af2c46ad58d4b3706b7c3cb24936d Author: Mika Westerberg Date: Thu May 7 08:06:48 2026 +0300 thunderbolt: Fix KASAN reported use-after-free when request is canceled commit a02188ddc24b7872f0c5e0c5873f827318717803 upstream. Alan reported that when doing stress testing sometimes KASAN notices use-after-free during control channel operation (stripped down keeping the relevant parts): BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt] Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 tb_cfg_request_sync+0x240/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Allocated by task 1760: __kmalloc_cache_noprof+0x1ee/0x550 tb_cfg_read_raw+0x1d3/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Freed by task 926: kfree+0x18f/0x4a0 tb_cfg_request_put+0xb7/0xe0 [thunderbolt] tb_cfg_request_work+0x82/0x120 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Second to last potentially related work creation: __queue_work+0x575/0xd00 queue_work_on+0x77/0x80 tb_cfg_request_cancel+0xc7/0x260 [thunderbolt] tb_cfg_request_sync+0x1f6/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 The last stack trace is helpful because it shows that we are cancelling a request and looking at tb_cfg_request_cancel() what might happen is that tb_cfg_request_work() completes right before tb_cfg_request_cancel() starts and because of this it will call schedule_work() queueing the same work to run again. However, it is already removed from the request_queue and reference count is dropped so when tb_cfg_request_work() triggers again it will access memory that is already released. Fix this so that we first make sure a cancelled request is not handed away from tb_cfg_request_find() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tb_cfg_request_cancel() after the work is canceled from running. Make tb_cfg_request_dequeue() release the request only if it was actually removed from the queue. Reported-by: Alan Borzeszkowski Fixes: d7f781bfdbf4 ("thunderbolt: Rework control channel to be more reliable") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit b9c3f43f5eab762025c03b882063ccd162caeb0b Author: Ian Lin Date: Fri Sep 4 16:00:46 2026 +0800 USB: serial: option: add Compal EXC-T1 support commit b51faf3f2e307f114854bbe6d495f03cd5370686 upstream. The Compal EXC-T1 is a Qualcomm MDM9207-based LTE modem which reports "EXC-x1" as its USB product string. It exposes diagnostic, modem, AT, and NMEA ports as vendor-specific interfaces with subclass 0x10 and protocols 0x01 through 0x04. Add exact interface matches for these four ports, leaving the ff/ff/ff interface unbound. Relevant output from usb-devices: T: Bus=03 Lev=02 Prnt=03 Port=03 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b7 ProdID=4d22 Rev=03.18 S: Manufacturer=CEI S: Product=EXC-x1 C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=10 Prot=01 Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=02 Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=03 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=04 Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=05 Driver=qmi_wwan Tested on a Compal EXC-T1 modem using an Ubuntu kernel build. The four serial interfaces bound to option and exposed ttyUSB3 through ttyUSB6. Assisted-by: Codex:GPT-5 Signed-off-by: Ian Lin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 77cd0c63d2a222c7757e50887d3ff62ea346860a Author: Sebastian Sjoholm Date: Thu Sep 3 20:00:29 2026 +0200 USB: serial: option: add Quectel RG660QB commit 6177bcd94be83f80a032c2e69a06606d325335b9 upstream. Add support for the Quectel RG660QB 5G module (USB ID 2c7c:013d). The interface layout is the same as the RG650V: If 0: DIAG ff/ff/30, 2 endpoints If 1: NMEA ff/00/00, 2 endpoints If 2: AT ff/00/00, 3 endpoints If 3: Modem ff/00/00, 3 endpoints If 4: QMI ff/ff/ff, 3 endpoints Match the serial interfaces on class/subclass/protocol so that the QMI interface is left to qmi_wwan. # lsusb -v -d 2c7c:013d Bus 004 Device 002: ID 2c7c:013d Quectel Wireless Solutions Co., Ltd. RG660QB-EU Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2c7c Quectel Wireless Solutions Co., Ltd. idProduct 0x013d bcdDevice 6.06 iManufacturer 1 Quectel iProduct 2 RG660QB-EU iSerial 3 f50119d0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0105 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 4 DIAG_SER_RMNET bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 CDEV Serial ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 CDEV Serial ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 7 RmNet Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0023 bNumDeviceCaps 2 SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000f Device can operate at Low Speed (1Mbps) Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds SuperSpeedPlus USB Device Capability: bLength 20 bDescriptorType 16 bDevCapabilityType 10 bmAttributes 0x00000001 Sublink Speed Attribute count 1 Sublink Speed ID count 0 wFunctionalitySupport 0x1100 bmSublinkSpeedAttr[0] 0x000a4030 Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus bmSublinkSpeedAttr[1] 0x000a40b0 Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus Device Status: 0x0000 (Bus Powered) Tested with an early sample of the module on a Quectel 5G EVB connected over USB 3 to a Raspberry Pi 5. Assisted-by: LLM Signed-off-by: Sebastian Sjoholm Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1e8ee2ef748377e03c488a26308a475f3510d05d Author: Ian Lin Date: Mon Aug 31 16:44:05 2026 +0800 USB: serial: option: add Compal EXM-G1x support commit 7f11480cda081de78a05d8c97073df66326b50b3 upstream. The Compal EXM-G1x is a Qualcomm SDX12-based LTE modem. Add support for its vendor-specific serial interfaces with protocols 0x30, 0x40, and 0x60. Relevant output from usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=04b7 ProdID=8217 Rev=05.04 S: Manufacturer=COMPAL S: Product=EXM-G1x C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan Tested on a Compal EXM-G1x modem. Assisted-by: Codex:GPT-5 Signed-off-by: Ian Lin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 48ec090c210525ef79d63f113c75c571b290e811 Author: Carlo Szelinsky Date: Wed Aug 12 13:42:28 2026 +0300 USB: serial: option: add Quectel EG060W commit cd243401994880b8b6810c53177bce56eebaece5 upstream. Add Quectel EG060W with product ID 0x6004. The three vendor-specific interfaces are DIAG, NMEA and AT; the CDC-NCM data interfaces are handled by the cdc_ncm driver. T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6004 Rev= 3.18 S: Manufacturer=Quectel S: Product=EG060W-EAAA S: SerialNumber=123456789ABCD C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr= 2mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Carlo Szelinsky Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d0cbc051c2d6d13e8799a30c47cf31cb699d2b17 Author: Zhao Dongdong Date: Mon Aug 17 15:14:27 2026 +0800 USB: serial: option: add support for SIMCom SIM8260C commit 35c950c9ec2c4c4d45dc9b63cfe8fca774ce33a0 upstream. Add support for SIMCom SIM8260C (1e0e:902b). T: Bus=08 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=1e0e ProdID=902b Rev= 5.04 S: Manufacturer=SIMCOM S: Product=SDXLEMUR-LITE-MTP _SN:120696AB S: SerialNumber=0123456789ABCDEF C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 5 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan_simcom E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 6 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 6 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=05(O) Atr=0d(Isoc) MxPS= 34 Ivl=1ms I:* If#= 7 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=(none) I: If#= 7 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=(none) E: Ad=89(I) Atr=0d(Isoc) MxPS= 34 Ivl=1ms Signed-off-by: Zhao Dongdong Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ae0da9a5c1ca95c20cc5feffd511ce6eae75924e Author: Johan Hovold Date: Thu Sep 3 18:31:46 2026 +0200 USB: serial: fix ioctl hangup race commit ae0e61d95677efa778379853e495d748e6efbf95 upstream. The tty ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Serialise the callbacks using the tty port mutex and add the missing checks to make sure the port has not been hung up before accessing port driver data or hardware. This specifically avoids dereferencing a NULL-pointer if a device is disconnected during lengthy break signalling. Note that TIOCGICOUNT and TIOCMIWAIT do not access port driver data or hardware and are therefore not affected by the race. Fixes: f34d7a5b7010 ("tty: The big operations rework") Reported-by: Nick Bowler Link: https://lore.kernel.org/all/CADyTPExB2kYOOwkO0JqGhKaYVDqO9uS9WCw0J=MCTdVhcGOogA@mail.gmail.com/ Reported-by: syzbot+473d7477c523b41d4046@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6a9087a4.4d659fcc.734b4.0013.GAE@google.com Cc: stable@vger.kernel.org # 2.6.26 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9b085a06a0a411b0bcdf18b61c3ebf1be1c72ffe Author: Johan Hovold Date: Fri Aug 21 17:45:45 2026 +0200 USB: serial: fix driver deregistration order commit 646e5b28b4fdbc1b828a2398d6ced2c1dd308a46 upstream. USB serial driver modules register one driver for the USB bus and one or more drivers for the ports on the USB serial bus. When unloading a driver module, the USB driver must be deregistered before the USB serial bus drivers so that I/O is stopped before unbinding the ports to avoid use-after-free in completion handlers accessing port data. Note that the "new_id" attributes must first be removed to prevent new ids from being added and triggering a probe of the USB driver after it has been deregistered. Fixes: 765e0ba62613 ("usb-serial: new API for driver registration") Cc: stable@vger.kernel.org # 3.4 Cc: Alan Stern Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ebd8fcaaacb66c15ae7e19d14619abe3762e0701 Author: Johan Hovold Date: Fri Aug 21 17:45:44 2026 +0200 USB: serial: fix dynamic id driver deregistration race commit 63594e8ffe097bc0b7639936f33799a7653dded2 upstream. Only free the dynamic ids after having deregistered the driver and removed the "new_id" attribute to avoid leaking any id added by a racing write to the attribute. Fixes: 93bacefc4cc0 ("USB serial: add dynamic id support to usb-serial core") Cc: stable@vger.kernel.org # 2.6.21 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 19e69376d27e125d7cfc4e53022dd4e6b6933ce4 Author: Johan Hovold Date: Tue Sep 15 14:40:11 2026 +0200 USB: serial: ssu100: fix baud rate overflow commit afc235a217360c6859068d2e37a4df305c4d1be2 upstream. The requested baud rate is incorrectly truncated to 16 bits so that line speeds above 65535 bps cannot be set. Use 32 bits for the rate and remainder while rejecting rates outside of [50,460800] to avoid having the divisor or remainder overflow. This issue was flagged by an LLM. Fixes: 52af95459939 ("USB: add USB serial ssu100 driver") Cc: stable@vger.kernel.org # 2.6.36 Cc: Bill Pemberton Assisted-by: LLM Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 67575907dc9fb541537eb35cae116e4308aacd91 Author: Johan Hovold Date: Tue Sep 15 14:40:12 2026 +0200 USB: serial: quatech2: fix baud rate overflow commit ec06546b43b612cefc851558981b4955c0ef9e46 upstream. The requested baud rate is incorrectly truncated to 16 bits so that line speeds above 65535 bps cannot be set. Use 32 bits for the rate while rejecting rates outside of [50,921600] to avoid having the 16-bit divisor overflow. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable@vger.kernel.org # 3.5 Cc: Bill Pemberton Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit dffc2b7f61e38514cd7ff6e1375d7fd1fb0a4124 Author: Jérémy Carrat Date: Thu Sep 10 18:26:09 2026 +0200 USB: serial: cp210x: add Corsair AX1500i Power Supply commit d84e27d87738634b92001500435ae4dadba10a13 upstream. The Corsair AX1500i power supply exposes its Corsair Link monitoring interface on a mini-USB port through an on-board CP2103, using a Corsair-specific product ID. Without the ID in the table no driver binds and no tty is created. Tested by forcing the driver association with echo 1b1c 1c02 > /sys/bus/usb-serial/drivers/cp210x/new_id and then setting the serial port to 115200 8N1. Adding the ID is sufficient to talk to the device: the tty reaches a USB-to-SMBus bridge sitting behind the UART, which identifies itself as "USB to SMB Bridge (Firmware by Ross Fosler)" version 0.9 and relays PMBus reads to the power supply controller. Input voltage and current, input and output power, internal temperature and fan speed were all read back on an AX1500i. [ 7.806181] usb 3-14: New USB device found, idVendor=1b1c, idProduct=1c02, bcdDevice= 1.00 [ 698.526754] usbcore: registered new interface driver cp210x [ 698.526767] usbserial: USB Serial support registered for cp210x [ 698.527863] cp210x 3-14:1.0: cp210x converter detected [ 698.529263] usb 3-14: cp210x converter now attached to ttyUSB0 The related AX1600i (1b1c:1c11, iProduct "USB API") is expected to be the same kind of device but has not been tested here, so it is not added. Cc: stable@vger.kernel.org Signed-off-by: Jérémy Carrat Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2f5b62f6534d336a62fdb9e88b186dd70b4323ef Author: Yuqi Xu Date: Sat Sep 19 16:48:12 2026 +0800 wifi: mac80211: handle empty FILS association request payload commit 5bfd4b0b40b79781d900cb2f7da0685070f53c67 upstream. fils_encrypt_assoc_req() accepts a (Re)Association Request frame whose last element is the FILS Session element. crypt_len is then zero and aes_siv_encrypt() is called with an empty plaintext. kmemdup() returns ZERO_SIZE_PTR for a zero-length allocation, so the unconditional sg_init_one() puts an invalid page into the scatterlist. With CONFIG_DEBUG_SG this triggers a kernel BUG in sg_set_buf(); without the debug check the bogus page is handed to the crypto backend. AES-SIV is defined for empty plaintext and the S2V result is then the complete output, so handle this case before the CTR step, which has nothing to encrypt. Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/325c048982d637a3af80d74ac5b36e9369b93f1e.1789751126.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0117f1aa189495e6f1ff608681678817995aee39 Author: Zihan Xi Date: Fri Sep 18 05:26:51 2026 +0000 wifi: mac80211: fix mesh fast xmit path deletion UAF commit ee3aadc43ea69d98f666431e787137ac0badbb85 upstream. mesh_fast_tx_cache() stores raw mesh_path pointers. Path deletion flushes the cache and then frees the path with kfree_rcu(), but a lookup that already holds the path can insert a new cache entry after the flush. The cache then points at freed memory. Set MESH_PATH_DELETED before flushing, and skip inserting a cache entry if the path or MPP path is already deleted. Check this under the cache walk lock so it is ordered with the flush. Use WRITE_ONCE() for the deletion flag updates because the cache check reads flags without taking state_lock. Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Link: https://patch.msgid.link/1daa7a98199fe6965c2da7c42717073a6fd39a0b.1789615568.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 56691ed9ef792f180e008a43294a4dc059fbeca2 Author: Zhao Li Date: Wed Sep 16 19:36:48 2026 +0800 wifi: mac80211: release mesh path quota on failed additions commit 7325a44474f20c1393a1c114c6811abce6ddfaf4 upstream. Repeated failed or duplicate mesh path additions can exhaust MESH_MAX_MPATHS while the path table holds fewer paths, which stops new paths to reachable destinations from being created. mesh_path_add() reserves a slot before allocating and inserting a path. If allocation fails, the function returns without releasing the slot. If the rhashtable insertion reports an error or an existing destination, the function discards its candidate but retains the reservation. No new path is installed in any of these cases. Release the reservation whenever the candidate is not installed. Fixes: ae76eef027f7 ("mac80211: return new mpath from mesh_path_add()") Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable") Cc: stable@vger.kernel.org Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113649.28315-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit cf0ddacce173890407ed3fa50c8ea9b3c0cc0e16 Author: Ruide Cao Date: Wed Sep 23 02:02:23 2026 +0800 wifi: mac80211: reject invalid 320 MHz CSA bandwidth commit 56e236759f0a8dc910c2ae7cd3c161f298ee5794 upstream. The HT/VHT channel definition validator can receive a 320 MHz bandwidth indication from a received CSA frame on a non-6 GHz link. It warns for this unsupported width but continues with an uninitialized vht_operation.chan_width, which is then read by ieee80211_chandef_vht_oper(). With panic_on_warn enabled, this lets a received frame panic the kernel. Reject the channel definition before entering the VHT operation conversion. This preserves the existing CSA fallback while avoiding both the warning and the uninitialized read. Fixes: 21c3f8f95554 ("wifi: mac80211: refactor STA CSA parsing flows") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Link: https://patch.msgid.link/bd68e360e06135c750397cb6be003a01a834a179.1787222001.git.vega.cover-letter@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f8ab6ae1fa360b0191252677f41e781dcb0ffe6e Author: Yuqi Xu Date: Sat Sep 19 16:46:20 2026 +0800 wifi: mac80211: minstrel_ht: validate fixed rate index commit 15fb9e3cea55fbc378261ce35a32b0f8828f0000 upstream. The fixed_rate_idx debugfs file is a plain u32 attribute, so any value can be written to it. minstrel_ht_update_stats() then copies the value into mi->max_tp_rate[] and mi->max_prob_rate, and minstrel_ht_set_rate() uses MI_RATE_GROUP()/MI_RATE_IDX() to index minstrel_mcs_groups[] (42 entries) and mi->groups[].rates[] (10 entries) with it. Writing e.g. 65535 selects group 4095 and rate index 15, far outside both arrays. The out-of-bounds entries are dereferenced and updated as struct minstrel_rate_stats (retry counts, etc.), so the invalid index corrupts adjacent kernel memory. With CONFIG_UBSAN_BOUNDS the access is reported as an array-index-out-of-bounds in minstrel_ht_set_rate(). Only a valid group/rate pair, or U32_MAX to disable fixed rate processing, can be used safely, so reject any other value when the debugfs file is written. The file is only reachable through a root-only debugfs mount, so this is not a privilege boundary. The out-of-bounds access is still a bug that must not be reachable through a writable debugfs attribute. Fixes: 24f7580e852b ("minstrel_ht: fixed rate mode through debugfs") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/288e6f6d30dc82ff40da502755e6666982f6b735.1789798000.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1d9644753d46c86b4e5c05bd6d9d35339ea27331 Author: Zhao Li Date: Thu Sep 10 14:52:51 2026 +0800 wifi: mac80211: keep fallback association elements alive commit a10a2f80476d166fd81c361ec0319493671b694e upstream. Associating to a non-transmitted MBSSID profile reads freed memory while determining the operating channel and applying HT capabilities. When an association response omits WMM, HT, or VHT information, ieee80211_assoc_config_link() parses the cached BSS IEs and copies the missing element pointers out of that fallback parse. For a non-transmitted MBSSID profile those pointers refer to merged-profile storage owned by the parse object, and the fallback block frees that object at its end. The copied pointers are used afterwards to determine the operating channel, configure bandwidth, and apply HT capabilities. Keep the fallback parse result alive until association setup finishes. Fixes: 5023b14cf4df ("mac80211: support profile split between elements") Cc: stable@kernel.org Assisted-by: LLM sparse kasan [reorder variable declaration] Signed-off-by: Zhao Li Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit df072db65fdaa34ad15e1d66fc06a53e3e97f778 Author: Zhao Li Date: Wed Sep 16 19:36:49 2026 +0800 wifi: mac80211: account proxy paths against the mesh path limit commit a5f35d4b112af1415ff06bd501c8cc26cc08aa8b upstream. Proxy-path churn can drive the interface path counter negative and let later mesh path additions exceed MESH_MAX_MPATHS. mesh_path_free_rcu() decrements the interface mpaths counter for entries from both the mesh and proxy path tables, but mpp_path_add() never reserves a slot in that counter. Removing or expiring a proxy path therefore returns a slot that was never charged. mesh_path_add() uses the same counter to enforce MESH_MAX_MPATHS, so once it falls below the number of installed paths the limit no longer holds. Reserve the shared quota before allocating a proxy path and release it on every unsuccessful addition. Mesh and proxy paths now share one 1024-entry budget, so mpp_path_add() can return -ENOSPC at that limit. Fixes: ece1a2e7e860 ("mac80211: Remove mesh paths when an interface is removed") Cc: stable@vger.kernel.org Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113649.28315-3-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 843d3a1e6f25027ac85f88f67b95d82c67306dee Author: Zhao Li Date: Wed Sep 16 19:37:35 2026 +0800 wifi: mac80211: drain PS delivery work during station teardown commit 67a9e80c3ca20c9044cd6ee72cd6278dd19b5023 upstream. Removing an AP or mesh station can notify the driver and wake TXQs after the station has already been removed from the driver, and can update num_sta_ps and the power-save queues after station cleanup has purged them. sta_deliver_ps_frames() tests sta->dead only before it starts delivery. A worker that passes that test can be delayed while teardown sets sta->dead and removes the station from the driver; when it resumes it still runs the full delivery. The existing cancel_work_sync() sits near the end of __cleanup_single_sta(), after the final driver state transition and after PS accounting and queue purging, so it drains the worker only once the state it has to protect has already changed. Before commit d34ba2168a3c ("mac80211: don't delay station destruction") cleanup was deferred through the same ordered workqueue as the delivery work, which kept the two ordered. Cancel the work after setting sta->dead and before moving the driver state, and move the existing cancellation to the start of __cleanup_single_sta(). The first drain closes the driver-lifetime window; driver callbacks during the remaining state transitions can still queue drv_deliver_wk through ieee80211_sta_block_awake(), so retain the second drain at the start of __cleanup_single_sta(). That drain also covers insertion failures, which reach cleanup without setting sta->dead. Fixes: d34ba2168a3c ("mac80211: don't delay station destruction") Cc: stable@vger.kernel.org Assisted-by: LLM sparse smatch coccinelle kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113735.31029-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 21a688cbeae0e682f03e91f1e7a7eedd60d9d4f2 Author: Zhiling Zou Date: Mon Aug 3 12:35:10 2026 +0800 wifi: mac80211: keep paired old chanctx alive commit 3412e9a800786d1dec4a58367db1cba275e7ef11 upstream. An in-place replacement keeps reciprocal replace_ctx pointers between the old WILL_BE_REPLACED chanctx and the new REPLACES_OTHER chanctx. However, the early free paths only consider assigned and reserved link users when deciding whether to free the old chanctx. That lets the old chanctx be freed too early while the replacement partner still points back to it, either when the last assigned link is released or when that link successfully reassigns to another existing context. Later unreserve and switch-finalization paths can then follow a stale replace_ctx pointer. Keep a paired old chanctx alive until the replacement pair has been torn down. Apply the same check to both __ieee80211_link_release_channel() and ieee80211_link_use_reserved_reassign(). If the replacement is later abandoned, ieee80211_link_unreserve_chanctx() already tears down the pairing before freeing the old chanctx once no users remain. Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/b9b582b0db3814f641648b8886bb50f9d68f93ac.1785730815.git.zhilinz@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ab7bee2cd55f665cb29fa0ace2ec14020e0a452e Author: Guangshuo Li Date: Wed Sep 16 15:37:36 2026 +0800 wifi: iwlegacy: 3945: free EEPROM data on remove commit f8ebe286394c0bbb4a6dbacb182a34ab6376922d upstream. il3945_pci_probe() calls il_eeprom_init(), which allocates memory for the EEPROM data. The probe failure paths release this allocation with il_eeprom_free(), but the remove path does not free it after a successful probe. As a result, the EEPROM data is leaked when the PCI device is removed. Free the EEPROM data in il3945_pci_remove() before releasing the mac80211 hardware structure. This issue was found by manual code inspection. Fixes: 073d3f5f1b3b ("iwlwifi: changing EEPROM layout handling") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260916073736.2952028-1-lgs201920130244@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 71f693a0ecccf36532dd2790f7969da6c71d5d23 Author: Tianchu Chen Date: Fri Sep 4 15:23:34 2026 +0000 wifi: cw1200: fix TX padding OOB read leaking heap data to device commit 7c1611780823b76219cb1478db53dfd890c4a9a2 upstream. The TX path rounds the transfer size up to the bus alignment (align_size(), up to 511 bytes for SDIO, 1 byte for SPI) but sends the padded length straight from the frame buffer, which has no room reserved for the padding. cw1200_data_write() therefore reads past the end of the frame and the bus transfer carries those bytes to the device. A bogus device can collect up to 511 bytes of kernel heap data per TX frame. The RX path does not have this problem: it allocates the skb with the aligned length (alloc_len) before reading. Compute the exact padding with the bus align_size() callback, make sure queued TX frames have tailroom for it, and zero the padding bytes before the transfer so nothing past the frame is exposed. This is not expected to change driver behavior on most cases: frame contents and transfer sizes are unchanged, only the content of the padding bytes (previously undefined stale memory, now zero), which the device never reads since the WSM header carries the real frame length. The skb expansion can only fail under memory exhaustion, in which case the frame is dropped like on the existing error paths of cw1200_tx(). Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/7982b4a7e64f74e2068790ec389ca680a081f730@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e1bcabc07efd029ab414894127411129ffdb8b48 Author: Sean Christopherson Date: Fri Sep 25 16:42:56 2026 -0700 KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy commit b6249c1d5665098c8bf12f8d3e4712bf04c775bc upstream. When walking shadow page tables, immediately terminate the walk if the root is a "dummy" root, i.e. a root whose top-level page table is backed by the zero page, but otherwise doesn't exist. If memslot creation races with a stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align, KVM will attempt to walk shadow page tables using the zero page and hit a NULL pointer deref. BUG: kernel NULL pointer dereference, address: 0000000000000021 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:__kvm_mmu_invalidate_addr+0xea/0x210 [kvm] Call Trace: kvm_mmu_invalidate_addr+0x92/0xe0 [kvm] __kvm_inject_emulated_page_fault+0x67/0x80 [kvm] ept_page_fault+0x160/0x850 [kvm] kvm_mmu_do_page_fault+0x102/0x1f0 [kvm] kvm_mmu_page_fault+0x8e/0x6b0 [kvm] vmx_handle_exit+0x163/0x640 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x960/0x2120 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f606d0b53bb Opportunistically harden the shadow walks against fully invalid roots, but WARN, as all callers are expected/required to pre-check for a valid root. Don't WARN in the dummy root case as the whole point of using a dummy root is to provide a root that's valid enough to enter the guest, i.e. it should Just Work for all flows except those that *need* to know about dummy roots. Alternatively, KVM could allocate a dedicated page and associated shadow page structure for the dummy root, which is very tempting as it such an approach should be more resilient against unexpected behavior. But that would be a much larger and thus riskier change than simply terminating walks of dummy roots. Fixes: 0e3223d8d00a ("KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots") Reported-by: Gabriel Schneider Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260925234256.2384816-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2db11598b59f16ddb6420693f9a4ac4efc3d4789 Author: Sean Christopherson Date: Thu Aug 13 14:44:03 2026 -0700 KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified commit 2abb25273c82061dd4670690c81c319c03740bf6 upstream. Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR. Fixes: 502d2bf5f2fd ("KVM: nVMX: Implement Enlightened MSR Bitmap feature") Cc: stable@vger.kernel.org Reviewed-by: Vitaly Kuznetsov Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 368ecbbef091ab5fe4f301be5cc660f05a823f20 Author: Nuno Sá Date: Mon Aug 31 16:07:18 2026 +0100 mtd: spinand: fix zero oobavail when no ECC engine is used commit 636fe10d8f3559210ff63108a208d39ea2e9c3bd upstream. Commit 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") made the OOB free bytes count conditional on having an ECC engine so that probing would not fail when none is requested. However mtd->oobavail is still assigned from ret just after that block, and ret is 0 there, so the device ends up advertising no available OOB bytes at all. mtd_oobavail() returns mtd->oobavail for MTD_OPS_AUTO_OOB, so a zero value makes every automatic OOB access fail with -EINVAL. JFFS2 fares worse: it keeps its cleanmarker in the OOB area on NAND and refuses to mount outright, reporting "inconsistent device description". No ECC engine also means no ooblayout was ever installed, which would make the count return -ENOTSUPP, so install the same fallback layout the on-die path already uses before counting unconditionally. Fixes: 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 3b987c5ccf9b47698a9bc163f14d0325e30566ae Author: Mehmet Fide Date: Tue Sep 1 09:39:06 2026 +0200 mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB commit 37adc9c5789c76db3b1ee7aeec3999b8503020d0 upstream. The controller transfers 64 spare bytes per page and the driver only implements the matching 64-byte ECC layout, so attach_chip() shrinks mtd->oobsize when the chip provides more. That clamp does not survive: nand_scan_tail() runs nanddev_init() after ->attach_chip(), and it restores mtd->oobsize from the memory organization, which still holds the value detected from the chip. The driver then transfers writesize plus the chip's full OOB size, the hardware ECC parity ends up at a different offset than the layout the controller was set up for, and every ECC-protected read fails with -EBADMSG. Measured on a Colibri VF61 (MX30LF4G28AC, 2048-byte pages, 112 bytes of OOB): with the clamp lost, UBI cannot read the erase counter headers of the pages U-Boot has just written, and the on-flash bad block table written by an older kernel reads back with ECC errors, so the board does not boot. Kernels before commit a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") are not affected because nothing overwrote the clamp there, which is why the same chip works with a v4.4 kernel and with U-Boot, whose copy of this driver has no memory organization to restore the value from. Edward Karpicz reported that the clamp no longer takes effect on this chip; see the link below. Instead of modifying the memory organization, keep the detected OOB size and give the driver its own mtd_ooblayout_ops: the same layout the NAND core uses for large pages, but computed on the first 64 OOB bytes instead of the whole OOB, so the ECC bytes stay where U-Boot and the old kernels put them. The data paths transfer writesize plus those 64 bytes, as the controller always has. Since mtd->oobsize now reports the chip's real spare size, fill the tail of oob_poi with 0xff after the 64 transferred bytes on ECC page reads: the core may copy the full mtd->oobsize from it, which would otherwise expose whatever the buffer held before. 0xff also matches what a raw read returns from flash, since the write path only ever programs the first 64 spare bytes. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Suggested-by: Miquel Raynal Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Cc: stable@vger.kernel.org Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 24319f25b641e55f84e55455092a39a2485c78d4 Author: Runyu Xiao Date: Wed Sep 2 15:05:42 2026 +0800 mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ commit 21f027016b1290d13c30b198ae7a00e6b3d1d5a5 upstream. The Cadence NAND interrupt handler uses both the IRQ lock and completion object. Registering the IRQ before initializing them leaves a window in which a pending interrupt can access uninitialized synchronization state. Initialize them before registering the handler. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 826170a49ca1315af6b293a02200585b1e2186d9 Author: Pei Xiao Date: Thu Aug 13 10:48:12 2026 +0800 mtd: block2mtd: Fix divide error when erase_size is zero commit b5965c4221165045e19736794ca5f48ae3d67142 upstream. The erase size is parsed from the "block2mtd" module parameter and can be set to zero. add_device() then evaluates if (size % erase_size) with a zero divisor, which triggers a divide error: divide error: 0000 [#1] PREEMPT SMP PTI RIP: 0010:add_device drivers/mtd/devices/block2mtd.c:296 [inline] RIP: 0010:block2mtd_setup2+0x592/0xda0 drivers/mtd/devices/block2mtd.c:459 Call Trace: block2mtd_setup+0x27/0xe0 drivers/mtd/devices/block2mtd.c:476 param_attr_store+0x214/0x310 kernel/params.c:589 module_attr_store+0x65/0x90 kernel/params.c:904 kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345 ... Reject a zero erase size before performing the modulo operation so the existing "erasesize must be a divisor of device size" error path reports the invalid argument and frees the device. Fixes: ea6d833a3fdd ("mtd: block2mtd: check device size") Reported-by: syzbot+b320a4d5f65a61dbbf89@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a7b58ba.ac361c09.22ff0a.0045.GAE@google.com/ Suggested-by: Jörn Engel Cc: stable@vger.kernel.org Signed-off-by: Pei Xiao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 9d61131acd742cf97ee64e453383e41b46568513 Author: Weiming Shi Date: Sun Sep 13 01:10:11 2026 +0800 nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() commit fa6778e030bed9841ddcdf96bc7018da9ac03562 upstream. nvmet_auth_challenge() receives its output buffer as a void pointer. sizeof(*d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes. A short AUTH_RECEIVE buffer can pass the check before the challenge is copied past the end of its allocation. Use the typed challenge pointer when calculating the response size. BUG: KASAN: slab-out-of-bounds in nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) Write of size 32 by task kworker/1:1H/64 Workqueue: nvmet_tcp_wq nvmet_tcp_io_work Call Trace: nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) nvmet_tcp_try_recv_pdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243) nvmet_tcp_io_work (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address is located 16 bytes inside of allocated 33-byte region [ffff888000554e80, ffff888000554ea1) Kernel panic - not syncing: KASAN: panic_on_warn set ... Cc: stable@vger.kernel.org Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Reported-by: co+77553a7fc66ac133@bugs.sh Closes: https://lore.kernel.org/all/Ah6QavQXwvshtqyUcYD1P1R7XE0ND9fB7lbV@bugs.sh/ Assisted-by: Codex:gpt-5.6 Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Weiming Shi Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit a9bc263e19856454ea276ca7eb289b559380f587 Author: Bean Huo Date: Fri Sep 4 12:51:55 2026 +0200 nvme-pci: add NVME_QUIRK_DMAPOOL_ALIGN_512 for Micron 4100AT commit c72f9f7bd23c91e944910d9bcbf12503d21a4a1f upstream. The Micron 4100AT fetches PRP Lists in 512 byte strides, but the driver allocates small PRP List descriptors in 256 byte strides. A descriptor in the last 256 bytes of a dmapool page makes the controller read past the page: the access lands on an adjacent IOVA, the IOMMU faults the command. That last block only became reachable with commit da9619a30e73 ("dmapool: link blocks across pages"), so this affects v6.4 and later. Align the small descriptor pool to 512 bytes, as commit ebefac564796 ("nvme-pci: 512 byte aligned dma pool segment quirk") already does for another controller with the same erratum. The last block then starts at offset 0xE00 and the fetch stays inside the page. Cc: # 6.4.x: ebefac564796: nvme-pci: 512 byte aligned dma pool segment quirk Cc: # 6.4.x Signed-off-by: Gaurav Sinha Signed-off-by: Bean Huo Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 03a0c21f0fd7a872953aae5714303d8f38d1e567 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Sep 15 11:19:56 2026 +0900 nvme-multipath: fix underflow in ANA log bounds checks commit 63fa2d9c9c37020bd2703fe2a6a38027b5abeb15 upstream. The number of ANA groups advertised through Identify Controller sizes the ANA log buffer. The ANA log header and group descriptors independently supply the number of groups and namespace IDs to parse. Both bounds checks subtract an untrusted object size from ana_log_size before comparing the current offset. If the object is larger than the buffer, the size_t subtraction underflows and lets the parser read beyond ana_log_buf. Check the current offset before the first subtraction and compare each object size with the remaining buffer instead. This rejects inconsistent ANA data before dereferencing a truncated group descriptor or walking an oversized namespace ID array. Fixes: 0d0b660f214d ("nvme: add ANA support") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit be54101992c2c5218be0e0a87827ccc96e3089af Author: Jiangshan Yi Date: Mon Oct 5 10:59:33 2026 +0300 tpm: fix off-by-four bounds check in tpm2_get_random() [ Upstream commit 9b522400bf5c082feb9a0037a053ea822a2c7e4d ] When the response carries the TPM2_ST_SESSIONS tag, tpm2_get_random() skips the 4-byte parameter size field before locating the random data, but the bounds check still validates the response length against TPM_HEADER_SIZE. A truncated response can pass the check and make memcpy() read up to 4 bytes past the response end, so stale buffer contents end up in the caller's random bytes. Fix this by checking the response length against 'offset', which already includes the skipped parameter size field. Cc: stable@vger.kernel.org # v6.12+ Fixes: 1b6d7f9eb150 ("tpm: add session encryption protection to tpm2_get_random()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260902074839.417419-1-yijiangshan%40kylinos.cn Signed-off-by: Jiangshan Yi Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260903035837.219284-1-yijiangshan@kylinos.cn Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 44ba9dc568c878b699d05e7cf699572dc9df4b59 Author: Willem de Bruijn Date: Sat Oct 3 20:57:55 2026 -0400 net: extend IPv6 exthdr detection of tunneled packets [ Upstream commit 5f0764cb1c81a9712bce605d38efe6d844a70b29 ] Commit c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") split skb_gso_has_extension_hdr() into mutually exclusive branches on skb->encapsulation. This did not yet address all paths: 1. With skb->encapsulation set, the outer header is not checked. IPv6 tunnels such as ip6_gre and ip6_tunnel add an outer Destination Options header by default (encap_limit). Their GSO packets skip software GSO, then skb_csum_hwoffload_help() sees the outer extension header and calls skb_checksum_help() on the GSO skb, which warns and drops it. 2. Tunnels over IPv6 without an outer transport header, such as ip6_tunnel, leave skb->transport_header at the inner transport header. skb_network_header_len() then spans the outer IPv6, tunnel and inner IP headers, a false positive. 3. UDP tunnels without an inner network header, such as SCTP-in-UDP or PSP, have no inner IPv6 header to check. Decide on the outer header alone. 4. Directly dereferencing inner_ip_hdr(skb)->version without skb_header_pointer() is unsafe. Instead, check ipv6_ext_hdr(nexthdr) on the outer IPv6 header and, if set, on the inner IPv6 header. Read the headers with skb_header_pointer(). Keep the skb_network_header_len() check when !skb->encapsulation to also catch encapsulated packets without skb->encapsulation (e.g., virtio). Use the same helper in skb_csum_hwoffload_help(). Its open coded test has the false positive of (2) and ignores the inner header. Background: checksum offload of tunneled packets invariants: Non-GSO skb: - If the inner packet is CHECKSUM_PARTIAL, Local Checksum Offload computes the outer checksum in software and the device offloads only the inner L4 checksum. - If the inner packet is CHECKSUM_NONE (e.g., SCTP-in-UDP, ESP-in-UDP, Remote Checksum Offload), the device offloads the outer UDP or GRE checksum instead. GSO skb: - A device with NETIF_F_GSO_UDP_TUNNEL_CSUM or NETIF_F_GSO_GRE_CSUM computes both inner and outer checksums per segment. The outer checksum is seeded with only the pseudo-header checksum. A NETIF_F_IPV6_CSUM device must parse through the outer headers to reach the inner ones. Fixes: c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") Cc: stable@vger.kernel.org Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260926140506.2335137-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski [ sashal: kept the !ipv6_has_hopopt_jumbo() exemptions; this tree still inserts the BIG TCP HBH jumbo header ] Signed-off-by: Sasha Levin commit 1f1bd9a3117f082eb891c0986c4f0e04cd974c9a Author: Aldo Ariel Panzardo Date: Sat Oct 3 18:54:58 2026 -0400 HID: multitouch: stop the release timer from being rearmed on remove [ Upstream commit 5acb2dace582f061aab5e14c399ac9480315f44b ] mt_remove() quiesces the sticky-finger timer before stopping the hardware: timer_delete_sync(&td->release_timer); sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group); hid_hw_stop(hdev); timer_delete_sync() waits for a running callback and dequeues the timer, but it does not stop the timer from being armed again. The transport is still delivering reports at that point, and the report path rearms it: if (app->quirks & MT_QUIRK_STICKY_FINGERS) { if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100)); A report that arrives after timer_delete_sync() has returned therefore leaves the timer queued. td is allocated with devm_kzalloc() against hdev->dev, so it is freed when the driver is unbound, after mt_remove() returns. When the timer fires afterwards, mt_expired_timeout() dereferences the freed td: struct mt_device *td = timer_container_of(td, t, release_timer); struct hid_device *hdev = td->hdev; if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags)) Simply moving the teardown after hid_hw_stop() does not fix this on its own, because mt_expired_timeout() calls mt_release_contacts(), which walks hdev->inputs; the timer still has to be quiesced before hid_hw_stop() tears the input devices down. Use timer_shutdown_sync() instead, which additionally makes any later mod_timer() a no-op, so neither ordering constraint has to be traded off against the other. This is the final-teardown pattern the function was introduced for, and hid-wiimote already uses it for the same reason. Fixes: 4f4001bc76fd ("HID: multitouch: fix rare Win 8 cases when the touch up event gets missing") Cc: stable@vger.kernel.org Reported-by: Sashiko AI review Closes: https://sashiko.dev/#/patchset/20260723224211.613112-1-you@example.com?part=1 Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Benjamin Tissoires Signed-off-by: Benjamin Tissoires [ sashal: Adapted the patch to replace del_timer_sync() instead of timer_delete_sync(). ] Signed-off-by: Sasha Levin commit 31028d7b970962fbeda1e9131405c76551094300 Author: Zhiling Zou Date: Sat Oct 3 19:22:53 2026 -0400 ipvs: bound LBLCR and LBLC cache growth [ Upstream commit 2a3c3de660f96865f303fd25f1285f2ffbfd521d ] ip_vs_lblcr_new() and ip_vs_lblc_new() create cache entries for every previously unseen destination address. The table max_size only tells the periodic collector to reclaim entries after the cache has already exceeded the limit. It does not reclaim entries that the attacker continues to use. Reject new cache entries once either table reaches max_size * 3 / 2. The extra headroom lets the periodic collector catch up while the existing scheduler fallback continues to use the selected destination when cache creation fails. New traffic therefore stays serviceable without growing the tables further. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Julian Anastasov Signed-off-by: Zhiling Zou Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso [ sashal: Retained kmalloc() instead of kmalloc_obj(). ] Signed-off-by: Sasha Levin commit 42b3332efacfd2140be4cd0dedad4fb96b8ae90e Author: Jens Axboe Date: Sat Oct 3 19:31:38 2026 -0400 io_uring: fix task_work add use-after-free with SQPOLL [ Upstream commit a92193c91e8839fe5fc209616ea95465ae4b919d ] For SQPOLL, the sqpoll thread runs task_work off its own list and doesn't need to be told about it, so it can pop and complete a request as soon as mpscq_push() has published it. If that was the last request holding the ring alive, io_ring_exit_work() then frees the ctx, stops the thread, and with it the tctx, while io_req_normal_work_add() is still looking at both after the push: BUG: KASAN: slab-use-after-free in io_req_normal_work_add+0x439/0x510 Read of size 4 at addr ff11000000ca0000 by task repro/55 (...) BUG: KASAN: slab-use-after-free in queue_work_on+0x25/0x70 Write of size 8 at addr ff11000000c3bd00 by task repro/55 Hold an RCU read lock across the add, like io_req_local_work_add() already does, and have io_ring_exit_work() wait for a grace period for SQPOLL rings as well before freeing the ctx. Reported-by: Jérémy Jean Link: https://lore.kernel.org/io-uring/20260924205056.3759980-2-Jeremy.Jean@oss.cyber.gouv.fr/ Fixes: af5d68f8892f ("io_uring/sqpoll: manage task_work privately") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe [ sashal: Adjusted hunk placement for the existing task-work implementation using llist_add() instead of mpscq_push(). ] Signed-off-by: Sasha Levin commit 3d6ba6be9bef13edcd4ad74f7cfdd0c34db4d2bc Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:22 2026 +0530 Bluetooth: btintel_pcie: reject oversized TX packets in send_frame() commit f771f96557a4d953a7e4d045870547271e36e819 upstream. btintel_pcie_send_frame() eventually copies skb->data into a fixed BTINTEL_PCIE_BUFFER_SIZE (4096) DMA buffer via memcpy() in btintel_pcie_prepare_tx(), with a 4-byte PCIe type header prepended. A user-space process with HCI_CHANNEL_USER access can inject an oversized packet and overflow the buffer. Reject packets larger than BTINTEL_PCIE_BUFFER_SIZE - BTINTEL_PCIE_HCI_TYPE_LEN on entry. Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c3a3842c109ac130c6db3aa0014cc8cd344928ad Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:21 2026 +0530 Bluetooth: btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() commit 7dbeb6935ac331b0cba6c41cabd8e9d02d5f64ea upstream. plen is u16 and computed as HDR_SIZE + dlen. For ACL/ISO frames dlen is a 16-bit field, so a value >= 0xFFFC wraps the sum, bypassing the "skb->len < plen" check and letting skb_trim() truncate the packet. Widen plen to u32 so the addition cannot wrap. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit bbc7de352f3f3864369c904aac944c7de84c6e7b Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:20 2026 +0530 Bluetooth: btintel: fix buffer over-read in btintel_hw_error() commit 40eb4b18ad167b63644c27fa67a7400ba050379a upstream. The "Exception info %s" print uses skb->data + 1, but the 12-byte payload is not guaranteed to be NUL-terminated and can be read past its end. Bound the print with "%.*s" and skb->len - 1. Fixes: 973bb97e5aee ("Bluetooth: btintel: Add generic function for handling hardware errors") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit d6d709981208567868c5c01ebd1bec5e5e7fdab0 Author: Chengfeng Ye Date: Sun Sep 27 01:29:35 2026 +0800 Bluetooth: hci_core: Serialize fragmented ISO packet queueing commit 1a572db43c057566771b485598ad2e66cb390821 upstream. The fragmented path in hci_queue_iso() calls __skb_queue_tail() without holding conn->data_q.lock. The socket lock serializes senders, but the transmit worker can concurrently remove packets from this queue using skb_dequeue(). After an insertion saves the old tail pointer, hci_sched_iso() can dequeue that packet and pass it to the driver. The driver can free the packet before the insertion resumes and writes to the old tail's next pointer, causing a use-after-free. Concurrent updates can also corrupt the queue. KASAN reported: BUG: KASAN: slab-use-after-free in hci_send_iso+0xc7d/0xe10 Call Trace: hci_send_iso+0xc7d/0xe10 iso_sock_sendmsg+0x710/0x900 __sys_sendto+0x34a/0x3a0 Allocated by task 86: __alloc_skb+0xdd/0x820 alloc_skb_with_frags+0x7e/0x770 sock_alloc_send_pskb+0x67a/0x820 bt_skb_sendmsg.constprop.0+0xc0/0x6c0 iso_sock_sendmsg+0x44e/0x900 Freed by task 90: kmem_cache_free+0xcb/0x3d0 vhci_read+0x33f/0x4d0 vfs_read+0x177/0xa20 Hold the queue lock across the entire fragment batch, as hci_queue_acl() does, to serialize insertion against dequeue while preserving fragment ordering. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 51f95ea451f25d7e3f048c0f438f04fa74688aae Author: Chengfeng Ye Date: Sun Sep 27 01:04:02 2026 +0800 Bluetooth: hci_core: Serialize ACL scheduling with channel deletion commit f4845ab191a4f686a5da481fbba90ed73bb693b0 upstream. hci_chan_sent() selects a channel under RCU but drops the read lock before accessing chan->conn and returning the channel. The ACL and LE schedulers then use its packet queue and update its transmit counters without any protection against channel deletion. After TX selects a channel and releases RCU, a disconnect command timeout on the separate request workqueue can run hci_conn_failed() and l2cap_conn_del(). hci_chan_del() can then unlink the channel, complete synchronize_rcu(), purge its queue and free it before TX resumes. This causes use-after-free both in hci_chan_sent() and in its callers. KASAN reported: BUG: KASAN: slab-use-after-free in hci_chan_sent+0x892/0x9b0 Workqueue: hci0 hci_tx_work Call Trace: hci_chan_sent+0x892/0x9b0 hci_tx_work+0x5e6/0xb70 Allocated by task 91: hci_chan_create+0xe3/0x350 l2cap_conn_add.part.0+0x12/0xa30 l2cap_chan_connect+0x110d/0x1b60 l2cap_sock_connect+0x310/0x530 Freed by task 99: hci_chan_del+0x11f/0x170 l2cap_conn_del+0x4f1/0x800 l2cap_connect_cfm+0x88c/0xd30 hci_conn_failed+0x150/0x250 hci_abort_conn_sync+0x3e3/0x800 hci_cmd_sync_run+0x7e/0xc0 hci_abort_conn+0x105/0x1f0 disconnect_sync+0x157/0x290 hci_cmd_sync_work+0x13c/0x290 Hold the existing device mutex across channel selection and transmission in both schedulers to serialize them with channel teardown. Keep timeout handling outside the critical sections because hci_link_tx_to() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission. Fixes: 3eff45eaf817 ("Bluetooth: convert tx_task to workqueue") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 4aa804d536cf219242768ed927818a6133d30339 Author: Linmao Li Date: Tue Sep 22 10:01:41 2026 +0800 Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systems commit 74847177eca5638827ab74cdf77f0b10fc40ca6c upstream. On 64-bit systems, outgoing BR/EDR connections always fall back to page scan repetition mode R2 with no clock offset once the system has been up for more than five minutes, even when inquiry found the peer only seconds earlier. This lengthens paging and can increase the risk of a Page Timeout. The inquiry cache stores jiffies in __u32 timestamps, but its age helpers subtract them from unsigned long jiffies. INITIAL_JIFFIES casts -300 * HZ through unsigned int, so jiffies crosses 2^32 five minutes after boot on 64-bit systems. Assigning it to __u32 then drops the upper 32 bits. In one trace, a 7.6-second-old entry (HZ=1000) was reported as 2^32 + 7620 ticks old and rejected by hci_acl_create_conn_sync(). hci_inquiry() is affected by the same truncation when checking the whole cache. 32-bit systems are unaffected because unsigned long is 32 bits wide there. Use unsigned long for both timestamps so they have the same width as jiffies on 32-bit and 64-bit systems, and update the debugfs format specifier accordingly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1239ef0fa809b5952fca679db3faa3e1c00e1dac Author: Chengfeng Ye Date: Sun Sep 27 19:04:50 2026 +0800 Bluetooth: hci_conn: Lock parent access during enhanced SCO setup commit 024e05f73a4c1263d031614bc36700ec135eecb4 upstream. Bluetooth: hci_conn: Lock parent access during enhanced SCO setup hci_enhanced_setup_sync() runs on the request workqueue without the hci_dev_lock held by its caller when setup was queued. Its CVSD capability check and find_next_esco_param() dereference conn->parent while the receive workqueue can unlink and release that parent. The following interleaving can cause a use-after-free: hci_enhanced_setup_sync() hci_disconn_complete_evt() load conn->parent hci_dev_lock() hci_conn_del(ACL parent) unlink SCO child drop link's parent reference clear child->parent release ACL parent bt_link_release() kfree(parent) hci_dev_unlock() read parent->features[0][3] The reference held for the queued SCO child does not keep its ACL parent alive after unlinking. Commit 42de40abe25d ("Bluetooth: hci_conn: fix the SCO setup context lifetime") protects the child stored in the queued context, but leaves these parent accesses unprotected. With a 40 ms diagnostic delay after loading conn->parent, an instrumented kernel based on fd179f8a05be, which already contains 42de40abe25d, reported: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0xda5/0xdf0 Read of size 1 at addr ffff888102204047 by task kworker/u17:0/93 Call Trace: hci_enhanced_setup_sync+0xda5/0xdf0 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x6b4/0x10e0 Allocated by task 92: __hci_conn_add+0x304/0x1df0 hci_connect_acl+0x349/0x3e0 hci_connect_sco+0x3b/0x9a0 sco_sock_connect+0x475/0xca0 Freed by task 94: kfree+0x121/0x3c0 bt_link_release+0x79/0xa0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x524/0xe30 hci_disconn_complete_evt+0x403/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 The accessed address is 71 bytes into the freed ACL parent, at its features[0][3] byte; the queued SCO child is a different object. The diagnostic preserves the loaded parent across the delay, matching the unmodified compiled capability check, and does not change the parent references or teardown path. Hold hci_dev_lock() across the codec switch, including every call to find_next_esco_param(), and release it on all selection errors. Keep configure_datapath_sync() outside the critical section because it waits for HCI events. Preserve parameter selection and existing return values. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Cc: stable@vger.kernel.org Assisted-by: GPT-6-Astra Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 52edf1c0e59dea37b8368c4a2559dca96b2fdfea Author: Chengfeng Ye Date: Sun Sep 27 01:28:31 2026 +0800 Bluetooth: hci_sync: Fix inquiry cache use-after-free commit 8ed67535fdff40ca652bcd4ac7da68d11d01bd34 upstream. The sync command worker holds hdev->req_lock, but inquiry-cache updates and flushes use hdev->lock. Both hci_acl_create_conn_sync() and hci_stop_discovery_sync() look up entries and read their fields without taking hdev->lock. After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire hdev->lock and flush the cache, freeing the entry. The worker then reads the freed entry while preparing a create-connection or remote-name-cancel command. The list traversal also races with cache updates and removal. KASAN reported these accesses: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_acl_create_conn_sync+0x5f1/0x650 hci_cmd_sync_work+0x13c/0x290 Allocated by task 90: hci_inquiry_cache_update+0x3e6/0x7d0 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 93: hci_inquiry_cache_flush+0x111/0x2b0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_stop_discovery_sync+0x3b1/0x3c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 86: hci_inquiry_cache_update+0x483/0x940 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 91: hci_inquiry_cache_flush+0x13e/0x2f0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 Hold hdev->lock across each lookup and all reads from its result. Copy the remote address before unlocking so discovery cancellation does not retain a cache entry pointer. Release the lock before sending synchronous HCI commands, since their completion handlers may need the same lock. Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a03ccf1ab77380d4c4a3c56552e12de4a83efa21 Author: Chengfeng Ye Date: Sun Sep 27 01:27:23 2026 +0800 Bluetooth: RFCOMM: Fix initial port reference race commit 2d696c1ed3468dcb62578a3911e687110d463520 upstream. For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference. The release path tests the bit separately from the install path setting it, so both can drop that reference. The synchronous hangup does not prevent this race: port->tty is not assigned until tty_port_open(), after installation. The following interleaving is possible: 1. Install and release each obtain a reference with rfcomm_dev_get(). 2. Release observes RFCOMM_TTY_OWNED clear. 3. Install sets RFCOMM_TTY_OWNED and drops the initial reference. 4. Release drops the same initial reference again. 5. TTY cleanup drops its reference and frees the device. 6. Release performs its final tty_port_put() on the freed port. KASAN reported: BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92 Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 88: rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370 process_one_work+0x661/0x1090 Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling. Fixes: 80ea73378af4 ("Bluetooth: Fix unreleased rfcomm_dev reference") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit f437579e059accd261af57e2a544dac5656369aa Author: Abdurrahman Hussain Date: Thu Sep 24 17:10:37 2026 -0700 i2c: xiic: don't clobber msg->len to signal block-read completion commit 840d8acc87925deb3c75566fde9ca81d2f47f98c upstream. At the end of a SMBus block read the BNB handler force-set tx_msg->len = 1 to push xiic_tx_space() to zero so the STATE_DONE branch would fire. Two problems: 1. tx_msg and rx_msg alias the same i2c_msg struct during a receive (see xiic_start_recv), so overwriting tx_msg->len also changes rx_msg->len. The i2c core's i2c_smbus_check_pec() then reads the PEC from the wrong offset -- buf[0] instead of buf[rxmsg_len + 1] -- and either mis-validates or returns -EBADMSG. 2. xiic_start_recv sets tx_pos = msg->len (typically 2 when PEC is enabled). xiic_tx_space() is unsigned msg->len - tx_pos, so setting msg->len = 1 with tx_pos = 2 underflows to 0xFFFFFFFF and xiic_tx_space() never compares equal to 0 -- the STATE_DONE check falls through to STATE_ERROR, giving -EIO. Instead, advance tx_pos up to msg->len. That drives tx_space to 0 without touching msg->len, preserving the buffer length that xiic_smbus_block_read_setup() already grew to cover the length byte, the payload and the optional PEC byte. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Reviewed-by: Shubhrajyoti Datta Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-3-df7e752332ef@nexthop.ai Signed-off-by: Greg Kroah-Hartman commit dc2ab61907b956c4df53303bd97f2555616a718b Author: Dinh Nguyen Date: Fri Sep 11 07:06:26 2026 -0500 EDAC/altera: Fix memory leak on dci allocation failure commit 3e4a10a4718e3d963ee4d6c5f26bc5ad57c1d2b1 upstream. Sashiko reports: "If devres_open_group() fails, the function returns -ENOMEM without freeing the dci structure allocated earlier with edac_device_alloc_ctl_info()." Free the dci structure if devres_open_group() fails. Fixes: c3eea1942a16 ("EDAC, altera: Add Altera L2 cache and OCRAM support") Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-4-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman commit fd3a7bf0d988b0878a1957df150edb35f81db87e Author: Xiang Mei Date: Fri Sep 18 15:57:53 2026 -0700 ALSA: ua101: reject mismatched capture/playback packet sizes commit 86f86e6fdedc33c5b8d38b9208b350f8accf57ee upstream. detect_usb_format() cross-checks bSubframeSize, bBitResolution and tSamFreq between the capture and playback interfaces, but never relates the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB gets a buffer of ua->playback.max_packet_bytes, while the number of bytes written into it is derived from the capture stream: capture_urb_complete() computes frames from the received capture packet and capture.frame_bytes, and start_usb_playback() and playback_work() multiply that by playback.frame_bytes. A device declaring a large capture wMaxPacketSize with few capture channels and a small playback wMaxPacketSize with many playback channels therefore memset()s and memcpy()s past the end of the playback buffer, in open() of the PCM node the driver registers during probe. usb_submit_urb() rejects the over-long iso_frame_desc[0].length with -EMSGSIZE, but only after the write. Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware declares proportional packet sizes and is unaffected. BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586) Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021 Call Trace: __asan_memset (mm/kasan/shadow.c:84) start_usb_playback (sound/usb/misc/ua101.c:586) playback_pcm_open (sound/usb/misc/ua101.c:679) snd_pcm_open_substream (sound/core/pcm_native.c:2829) snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932) snd_pcm_playback_open (sound/core/pcm_native.c:2891) snd_open (sound/core/sound.c:166) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:996) vfs_open (fs/open.c:1101) path_openat (fs/namei.c:4837 fs/namei.c:5000) do_file_open (fs/namei.c:5029) do_sys_openat2 (fs/open.c:1417) __x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the object at ffff8881098f3c00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 0 bytes inside of allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8) Cc: stable@vger.kernel.org Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Reported-by: Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260918225753.1278505-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 413211dd31cb2ef2fc99fb0aa1a037a97509502c Author: Kyle Zeng Date: Thu Sep 17 12:56:43 2026 +0200 ALSA: seq: Serialize compat port-info ioctls commit 95b2e0361c88753afa030c10698be0a1a5b67650 upstream. The native sequencer ioctl path serializes handler calls with client->ioctl_mutex, but the translated port-info compat path invokes the same handlers through snd_seq_kernel_client_ctl() without taking that mutex. This lets concurrent compat CREATE_PORT requests pass the port-count check before any request reaches the serialized insertion. The computed integer port index can then exceed the address field range and wrap to an existing index. Subsequent subscriber teardown can resolve the duplicate address to the wrong port and access a freed subscriber. Take ioctl_mutex while dispatching converted port-info requests, matching the native ioctl path. All translated port-info commands share this helper, so their accesses to the client port state are serialized as well. Fixes: b3defb791b26 ("ALSA: seq: Make ioctls race-free") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol gpt-6-astra Signed-off-by: Kyle Zeng Signed-off-by: Bruno Produit Link: https://patch.msgid.link/20260917105643.90102-1-bruno.produit@trailofbits.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6833f1893ac2ec40016c348779af63debf3700d2 Author: Zimeng Li Date: Sun Sep 27 09:09:11 2026 +0800 ASoC: qcom: lpass-cpu: use DAI table index for playback constraints commit ca51771c8efde5df05476ac98dd1b2af4e2b149f upstream. The DAI ID is a hardware port ID and is not necessarily the index of the corresponding entry in variant->dai_driver. When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code currently uses dai_id to index variant->dai_driver. This is incorrect for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S DAI has ID 4 while it is the only entry in the DAI driver table. If that DAI is configured for QUAD01 and probe reaches this branch, the code writes beyond that single entry via dai_driver[4] instead of updating the DAI being processed. Use the loop index i when updating the current DAI's playback channel constraints, while retaining dai_id for indexing the hardware-port specific playback SD-line mode array. This fixes the incorrect DAI table access for platforms where the DAI ID does not match its position in the driver table. Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary") Cc: stable@vger.kernel.org Signed-off-by: Zimeng Li Assisted-by: LLM-assisted source analysis Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260927010911.51980-1-me@lizi.moe Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4e337c24c0a97fcdb394f954208971de5d372066 Author: Jiangshan Yi Date: Mon Sep 14 18:45:51 2026 +0800 ASoC: codecs: rt1017-sdca-sdw: fix uninitialized stream_config->type commit 174d160884199cad97413f33fe1b56027dc0d3e1 upstream. stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. While at it, use snd_sdw_params_to_config() helper instead of open-coding the same logic. Fixes: 2b7aecd58528 ("ASoC: rt1017: Add RT1017 SDCA amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260914104551.377880-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1c251426bb67de5cbfd3b5550bd5983736e8b9c7 Author: Jiangshan Yi Date: Mon Sep 14 18:44:56 2026 +0800 ASoC: codecs: max98363: fix uninitialized stream_config->type commit bcd61aa247c28b721ac21dda6e4135f75a2de29f upstream. stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. Fixes: 18c0af945fa3 ("ASoC: max98363: add soundwire amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260914104456.376666-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cd05ffc45e5d101d2c4ff3d793ab38773b662319 Author: Paul Mbewe Date: Wed Sep 30 16:56:27 2026 +0200 serial: sc16is7xx: refill TX FIFO below trigger using fresh TXLVL commit 527484911a40f6e84cf47e8bc490f7da61ab4151 upstream. sc16is7xx_handle_tx() reads TXLVL once and sizes the hardware TX FIFO write from that value. TXLVL reports free space in the hardware TX FIFO. On this SPI-backed path, hardirq/softirq activity, RT scheduling, and waiting for synchronous SPI transfers can delay the refill while the UART continues draining. The TXLVL value can therefore become stale before the hardware TX FIFO write completes. One failing ftrace with the default 8-free-space trigger showed: tx_start txlvl=9 txlvl_read_us=580 tx_pre_write sent=9 pre_write_us=16 tx_segment sent=9 seg_us=364 tx_post_write txlvl_before=9 sent=9 txlvl_after=12 pending_after=29 post_gap_us=12 post_txlvl_us=130 The driver read 9 free spaces and wrote 9 bytes to the hardware TX FIFO, but the post-write TXLVL read still reported 12 free spaces while 29 bytes remained queued in the xmit kfifo. Even allowing for the post-write read window, the hardware TX FIFO had not been filled below the 8-free-space trigger, so no new threshold crossing was expected. The captured failing samples had the same pattern: data remained queued in the xmit kfifo while post-write TXLVL remained above the hardware trigger. The hardware TX FIFO then drained empty before another refill was requested, producing an unintended gap on the wire. Fix this by re-reading TXLVL after each hardware TX FIFO write while data remains queued in the xmit kfifo. If TXLVL is still at or above the trigger, top up the hardware TX FIFO again. Stop when the xmit kfifo is empty or a TXLVL read confirms that hardware TX FIFO free space is strictly below the trigger. Stopping when TXLVL was equal to the trigger still allowed TX gaps in the tested workload. Continuing until TXLVL was strictly below the trigger eliminated the observed gaps caused by stale-TXLVL under-fill. Program the hardware TX trigger explicitly through TLR using the same constant as the refill-loop threshold. This prevents the software refill condition from diverging from the programmed hardware trigger. Tested on SC16IS752 over 1 MHz SPI on an i.MX6ULL single-core PREEMPT_RT system, transmitting RS-485 at 115200 baud 8N1 under continuous Modbus RTU load. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@kernel.org Reported-by: Tobias Gannert Link: https://lore.kernel.org/linux-serial/20260623112225.82386-3-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Reviewed-by: David Laight Link: https://patch.msgid.link/20260930145628.566535-2-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit c0c172ebed926409822e76a3d4b8db9fc0105721 Author: Paul Mbewe Date: Wed Sep 30 16:32:07 2026 +0200 serial: sc16is7xx: fix TX gap caused by kfifo circular buffer wrap-around commit abfafa6fc3c17b7dffa5dce3acc8dba70ed656b9 upstream. kfifo_out_linear_ptr() returns only one contiguous linear segment of the xmit kfifo. When transmit data wraps around the end of the kfifo, only the first segment up to the buffer end is sent. The remaining data at the start of the kfifo is not sent until the next TX interrupt fires, resulting in a visible mid-frame TX gap on the wire. The resulting gap is unintended: data remains queued in the xmit kfifo, but the hardware TX FIFO drains empty before the remaining segment is sent. Such gaps can break timing-sensitive serial protocols such as Modbus RTU. Modbus RTU requires a message to be transmitted as a continuous stream. For baud rates above 19200, the Modbus Serial Line guide recommends a fixed 750 us inter-character timeout. On the tested 115200-baud system, oscilloscope measurements showed mid-frame gaps exceeding that value. Receivers using the recommended timeout may therefore discard the incomplete message. The incomplete transfer also causes unnecessary TX interrupts: instead of using all available hardware TX FIFO space in one go, the driver requires an extra interrupt to send the remaining segment after the wrap. After the tty xmit buffer was converted to a kfifo, the driver used uart_fifo_out() to copy data into a linear staging buffer, allowing a transfer to span the kfifo wrap-around boundary. Commit 133f4c00b8b2 ("serial: sc16is7xx: fix TX fifo corruption") replaced uart_fifo_out() with a single kfifo_out_linear_ptr() call to remove the shared TX/RX buffer. Since kfifo_out_linear_ptr() exposes only one contiguous segment, that change lost the wrap-around handling. Fix this by calling kfifo_out_linear_ptr() in a loop, advancing through all contiguous segments until the available hardware TX FIFO space is exhausted or the xmit kfifo is empty. This fixes the kfifo wrap-around gap independently of the stale-TXLVL refill issue. Tested on SC16IS752 over SPI driving RS-485 at 115200 baud 8N1 on an i.MX6ULL-based board. Oscilloscope measurements confirmed mid-frame breaks at the kfifo wrap-around boundary before the fix; no such breaks were observed afterward. Fixes: 133f4c00b8b2 ("serial: sc16is7xx: fix TX fifo corruption") Cc: stable@kernel.org Reported-by: Tobias Gannert Reviewed-by: Joachim Knorr Link: https://lore.kernel.org/linux-serial/20260623112225.82386-2-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Link: https://patch.msgid.link/20260930143207.542930-1-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit 00d51b4182864aca17c59359d3d977ae474e7b84 Author: Wentao Liang Date: Thu Sep 17 15:58:34 2026 +0000 serial: vt8500: Fix clock reference leak in vt8500_serial_probe() commit 9d8955281d9229a899e2041659a59b389027b711 upstream. of_clk_get() returns a clock with a reference that has to be released with clk_put(). If clk_prepare_enable() fails the function returns without doing so, leaking the reference. Add the missing clk_put() on that error path. Fixes: 12faa35ae5cb ("serial: vt8500: UART uses gated clock rather than 24Mhz reference") Cc: stable@kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917155834.2161361-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit fbeadc8352540b55d998f2dba82b8df9d9bd8341 Author: Simon Gassner Date: Thu Oct 1 08:05:39 2026 +0200 serial: tegra: don't clear the Tx FIFO on an Rx-only reset commit 8aebfde6e84dceb7d47fe8001e50b754eb45d5df upstream. tegra_uart_fifo_reset() applies the Tegra30 workaround for "cannot clear the Tx FIFO while FIFO mode is enabled" unconditionally: it leaves FIFO mode, writes the requested FCR clear bits, and re-enters FIFO mode. Leaving FIFO mode empties both FIFOs, so an Rx-only reset discards queued Tx data as well. The break handler in tegra_uart_decode_rx_error() calls it with UART_FCR_CLEAR_RCVR only. On a half-duplex RS485 board whose Rx line is pulled low while the transceiver drives the bus, every transmission raises a spurious break, and all but the first character of the frame is lost. Only take the FIFO-mode path when the caller actually asked for CLEAR_XMIT. Likewise only wait for TEMT in that case: with the Tx FIFO deliberately left intact, that loop would otherwise spin for a full frame time in hard IRQ context with the port lock held. Tested on a Colibri T30 (Tegra30) with Rx DMA: - Break during transmission: the reset still fires from tegra_uart_decode_rx_error(), and the complete frame now reaches the peer. Before this change only the character in the shift register was sent. - Internal loopback with a generated break: the Rx FIFO is correctly cleared by the plain FCR write, and subsequent receive works with no frame, parity or overrun errors. Fixes: e9ea096dd225 ("serial: tegra: add serial driver") Cc: stable@kernel.org Signed-off-by: Simon Gassner Link: https://patch.msgid.link/20261001060539.32659-1-simon.gassner@noxsystems.com Signed-off-by: Greg Kroah-Hartman commit 547c742f3b4acd4634eec47e9bff8731b55059a0 Author: Wentao Liang Date: Thu Sep 17 15:56:50 2026 +0000 serial: ma35d1: Fix clock reference leak in ma35d1serial_probe() commit 98401cf912fe8a081ef8e500c421b6d957b55a99 upstream. of_clk_get() returns a clock with a reference that has to be released with clk_put(). ma35d1serial_probe() never does that, so the reference is leaked on the probe error paths and also when the port is removed. Release it on the error paths and in ma35d1serial_remove(). Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support") Cc: stable@kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917155650.2161274-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit fd0085471cf07e058554b0f21f701f3b9de05d86 Author: Johan Hovold Date: Thu Sep 10 15:08:15 2026 +0200 serial: fix TIOCMIWAIT race commit 40adffec8c0090533dfaa863ced7901b60bbf1dc upstream. The task state must be updated before checking the wakeup condition to avoid missing a racing modem status update. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260904115542.E20D11F00A3D@smtp.kernel.org Cc: stable@kernel.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f5ce06e648d775cc1ccf66f4f594bb8b559a7d8e Author: Fan Wu Date: Wed Sep 9 08:40:02 2026 +0000 serial: 8250_bcm7271: fix use-after-free in brcmuart_remove() commit 189b9dc8c96ec9486482f27c1372b04a7152175e upstream. brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout quirk of the 8250 core when hardware flow control is enabled; the timer callback brcmuart_hrtimer_func() dereferences priv. brcmuart_remove() cancels the hrtimer before it unregisters the port, so a receive-timeout interrupt that arrives in between re-arms the timer. After devm frees priv, the callback runs on freed memory. Unregister the port before cancelling the hrtimer. serial8250_unregister_port() shuts the port down and frees its IRQ, so brcmuart_handle_irq() can no longer restart the timer, and the final hrtimer_cancel() drains any timer that was armed before or during the unregister. This issue was found by an in-house static analysis tool. Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260909084002.686911-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit fb668620e3b163962dabe1a674725a07aa44ff4a Author: Fan Wu Date: Sun Sep 27 05:59:57 2026 +0000 tty: serial: max3100: shut down timer before freeing port commit db0949bbd06db0a75b4b1076f1e25194be7d956a upstream. max3100_shutdown() stops the polling timer but returns early during system suspend. If the SPI device is unbound before resume, the serial core does not call max3100_shutdown() again, so max3100_remove() frees the port while the timer remains armed. max3100_timeout() may then access the freed port and re-arm the timer. Add final timer teardown to max3100_remove() and use timer_shutdown_sync() to prevent a racing callback from re-arming it. Also free the IRQ and destroy the workqueue there before freeing the port. Keep timer_delete_sync() in max3100_shutdown() so that a subsequent open() can re-arm the timer. The workqueue is created before request_irq() and destroyed on both request_irq() failure and normal shutdown. Its presence at remove thus identifies the IRQ left registered when suspend bypasses shutdown. Free the IRQ before destroying the workqueue, in both max3100_shutdown() and max3100_remove(), and cancel the pending work in between. free_irq() waits for a running interrupt handler to finish and no new handler can start afterwards, so a racing handler cannot queue work on a workqueue that is being destroyed; the force_end_work check in max3100_dowork() only narrows that window, as a handler delayed between the check and queue_work() could still run after the teardown has cleared the workqueue pointer. Cancelling the work also keeps destroy_workqueue() from waiting on a queued work item in case remove() ever runs while the freezable workqueue is still frozen, e.g. device removal during the resume window, before workqueues are thawed. This issue was found by an in-house static analysis tool. Fixes: 7831d56b0a35 ("tty: MAX3100") Cc: stable@kernel.org # 6.2+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260927055957.561030-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 3bc82999fb85cecc7eb6ec1755ee7d698aa1e783 Author: Johan Hovold Date: Thu Sep 3 18:37:36 2026 +0200 tty: abort break signalling on hangup commit 845a2737e0f5ffe5ca8d38de556012b0c9472cdd upstream. The break ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Drivers must handle this race, but TCSBRK and TCSBRKP should still be aborted to avoid calling back into the driver after a user-controlled timeout (possibly even after the tty has been reopened). Note that drivers should disable any break state on shutdown so just return on hangup (calling break_ctl() again is racy and will most likely fail for drivers handling the race). Fixes: f34d7a5b7010 ("tty: The big operations rework") Cc: stable Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260903163736.1499280-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 26fc3e51879184c3669babe1b4f82df0b3423d51 Author: Viken Dadhaniya Date: Tue Sep 15 18:56:28 2026 +0530 tty: serial: qcom_geni_serial: Keep console RX functional after deep idle commit 63ef71d1474b5417b5b2dec700cd251c44a570d9 upstream. At baud rates up to 115200, the serial console uses only a 1 kBps keepalive vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path active but does not request a QUP Core 2X clock rate. When the CPU enters a deeper idle state, the missing Core clock vote can leave the console RX path unresponsive. Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz vote at higher baud rates, so that console RX remains functional after deep idle transitions. Fixes: 7cf563b2c846 ("tty: serial: qcom_geni_serial: Add interconnect support") Cc: stable@kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-2-f78eb611204e@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 88f6ecb058801e9ce7b9aabc966530118d7cd53c Author: Joshua Rogers Date: Mon Aug 3 16:10:55 2026 +0200 tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup commit 03b49c991abb8d021ca6fe51cd173447236b0552 upstream. vcc_cleanup() sets port->tty to NULL without holding port->lock, racing with vcc_event() LDC callbacks that read port->tty under port->lock and then use tty->port. This can cause a use-after-free when the callback dereferences tty->port after cleanup has already destroyed and freed it. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260803-aisle-tty-vcc-v2-2-a50bc9b15193@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 6f1a08ef02825b440126c406ea63ef6128888e15 Author: Joshua Rogers Date: Mon Aug 3 16:10:54 2026 +0200 tty: vcc: zero-initialize control packet in vcc_send_ctl() commit 1f71f565e3585da1098ff19ca3c24687dab59185 upstream. The stack-allocated struct vio_vcc pkt was partially initialized, leaving the tag.stype_env field uninitialized before being sent via ldc_write(), potentially leaking kernel stack data to the LDC peer. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260803-aisle-tty-vcc-v2-1-a50bc9b15193@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 3062229f954aeb4bd88434878deeb8aa5a53a121 Author: Johan Hovold Date: Fri Sep 11 11:01:32 2026 +0200 tty: amiserial: fix broken TIOCMIWAIT commit 615f35fd5aee169cc4881a8594f2fa234a4d0bb8 upstream. A change replacing interruptible_sleep_on() inadvertently broke the TIOCMIWAIT implementation which now immediately returns -EIO (unless there is a racing modem status update). Replace the old hangup (and signal) detection with a check for the TTY_IO_ERROR flag which is set on hangup. Fixes: 591cee0a3563 ("tty/amiserial: avoid interruptible_sleep_on") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/20260910132029.D80801F00898@smtp.kernel.org Cc: stable@kernel.org # 3.14 Cc: Arnd Bergmann Signed-off-by: Johan Hovold Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260911090132.723531-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 59e5ba78764419dc5c03bc99dc92d438fef0ce7a Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon Aug 3 22:45:56 2026 +0800 tty: vt: fix memory leak in vc_allocate() commit 5b114bfc1dfd88f9d50822d532f7f1fce0f7388a upstream. If the screen buffer allocation fails in vc_allocate(), the error handling path jumps to `err_free`. However, this path fails to release the unicode screen map attached to `vc->uni_pagedict_loc`. During the early stages of vc_allocate(), the unicode screen map is either newly allocated via con_set_default_unimap() or shares the default unicode map from a previously initialized console (which increments its refcount). If the subsequent kzalloc() for the screen buffer fails, the err_free path frees the vc structure but leaves the attached uni_pagedict with an elevated refcount. This results in an unreferenced object memory leak, as the reference to the dictionary is lost and its refcount can never reach zero. This issue was discovered by DevGen (an automated virtual device modeling fuzzer based on Syzkaller). During fuzzing with kernel fault injection (failslab) enabled, the fuzzer forcefully failed the kzalloc() for the screen buffer, exposing this error-handling path leak. Fix this by checking *vc->uni_pagedict_loc and calling con_free_unimap(vc) in the err_free path before kfree(vc). This safely decrements the refcount and releases the dictionary memory if this was the last reference. The explicit check is added to maintain consistency with other callers. Fixes: 34902b7f2754 ("tty: vt, get rid of weird source code flow") Cc: stable Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Link: https://patch.msgid.link/20260803144556.163856-1-25181214217@stu.xidian.edu.cn Signed-off-by: Greg Kroah-Hartman commit 549c04df02f1bb5a10342f32e2c87f5d27c97279 Author: Jie Deng Date: Mon Aug 10 10:36:26 2026 +0800 usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe commit e5052f2c5c73c1dcca42bafc0bc737af2b2af059 upstream. The Cadence USBSS controller is a two-function PCI device. The first probed function allocates the driver data and stores it with pci_set_drvdata(), while the second function reuses it via pci_get_drvdata() when pci_is_enabled() reports that the first function has already been probed. When the second function is probed while the first one has been enabled but has not yet set its driver data, pci_get_drvdata() returns NULL, and the subsequent wrap->devfn assignment dereferences a NULL pointer and crashes the kernel. logs: Call trace: cdns3_pci_probe+0xa4/0x300 local_pci_probe+0x44/0xa8 pci_call_probe+0x54/0x158 pci_device_probe+0x84/0x100 really_probe+0x184/0x3d0 __driver_probe_device+0x80/0x178 driver_probe_device+0x44/0xe8 __driver_attach+0xec/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x28/0x38 bus_add_driver+0x110/0x238 driver_register+0x64/0x128 __pci_register_driver+0x50/0x60 cdns3_pci_driver_init+0x28/0x38 do_one_initcall+0x5c/0x280 do_initcalls+0x104/0x1d8 kernel_init_freeable+0x140/0x218 kernel_init+0x28/0x1f8 ret_from_fork+0x10/0x20 Return -EPROBE_DEFER in this case so that probing is retried after the first function has completed its probe. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Jie Deng Acked-by: Peter Chen Link: https://patch.msgid.link/20260810023626.70669-1-dengjie03@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit cc448700db656cceb4b411bf99a2e7132144d035 Author: Fan Wu Date: Wed Sep 9 09:56:55 2026 +0000 usb: cdns3: fix use-after-free in cdns3_gadget_exit() commit ebe9b68c396792c15d0ac690d592e449e74ed804 upstream. cdns3_gadget_start() arms two works on system_freezable_wq: pending_status_wq for the deferred ep0 status stage and aligned_buf_wq for realigned request buffers. Both handlers use the cdns3_device the works are embedded in, and cdns3_pending_setup_status_handler() also calls the ep0 request completion. cdns3_gadget_exit() does not wait for these works. It frees all endpoints and aligned buffers and drops the last reference to the gadget device, which frees priv_dev, so a work queued before the exit can run after the free. Fix this by waiting for both works after the gadget driver is unbound and the IRQ is freed, when no new work can be queued, and before the endpoints and buffers are released. This issue was found by an in-house static analysis tool. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Reported-by: Sicong Huang Closes: https://lore.kernel.org/linux-usb/7f5719b.8700.18f67b324d3.Coremail.congei42@163.com/ Suggested-by: Sicong Huang Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Acked-by: Peter Chen Link: https://patch.msgid.link/20260909095655.694527-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit d43c75a1571bea153f4b2df3972b13ac2b2fbaa7 Author: Jameson Thies Date: Thu Sep 17 03:20:08 2026 +0000 usb: typec: ucsi: displayport: Current CAM OOB index fixup commit ea31c6498c61307dc0d8ce338a7f268cb8cbdd57 upstream. Update ucsi_displayport_enter() to return invalid error when the PPM reports an current alternate mode greater than or equal to UCSI_MAX_ALTMODES. While here, remove 0xff current cam assignment on failed GET_CURRENT_CAM response. Fixes: 04cec690b1fd ("usb: typec: ucsi: displayport: Fix OOB altmode array index") Cc: stable Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Signed-off-by: Jameson Thies Link: https://patch.msgid.link/20260917032008.1701888-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit 10ceba717a062b513498069fa3175bd8170303da Author: Prashanth K Date: Wed Sep 16 09:58:08 2026 +0530 usb: typec: ucsi: Get the connector fwnode based on reg value commit 6c51f09c6db5868a5090e8dd4d7764660c87f1ad upstream. ucsi_find_fwnode() currently maps UCSI connectors to Device tree connector nodes based on the order in which connector child nodes are described in DT. This can fail because the ordering of child nodes isn't guaranteed in Device-tree. For example, DTB may contain connector@1 before connector@0, causing connector numbers to be associated with the wrong fwnode. As a result, role switch and Type-C notifications can be delivered to the wrong remote endpoints. Fix this by using the "reg" property of each connector to match its corresponding fwnode. While at it, if the reg property isn't present, then fall back to the old method. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable Signed-off-by: Prashanth K Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260916042808.2879079-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 432b58cd959e594909a581b4974396cdbc9d4ca1 Author: Fan Wu Date: Tue Sep 8 06:02:15 2026 +0000 usb: typec: ucsi: glink: fix use-after-free of ucsi on remove commit 63b269ec537dc0fd26d0bd64872c26860d108c9d upstream. The pmic_glink client is released by the devres cleanup, which runs after pmic_glink_ucsi_remove() has returned, so its notification callbacks can queue work until then. Work that runs after ucsi_unregister() has been called touches freed state: it dereferences the connector array that ucsi_unregister() freed, or registers and unregisters the instance a second time. Disable both work items with disable_work_sync() before unregistering, and unregister only if the instance is still registered. This issue was found by an in-house static analysis tool. Fixes: 62b5412b1f4a ("usb: typec: ucsi: add PMIC Glink UCSI driver") Cc: stable Assisted-by: Codex:gpt-5.6 Link: https://lore.kernel.org/r/20260227190430.889-1-nathan.c.rebello@gmail.com Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260908060216.616045-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 4b6823ce0e548491cb9663303cba28e18d351096 Author: Radhey Shyam Pandey Date: Sun Sep 6 18:49:41 2026 +0530 usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect() commit c4b27b3605788bbf9e4251f3cd4ab94645ab036f upstream. tps6598x_connect() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity. typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs. Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero. Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable # 5.15+ Reviewed-by: Heikki Krogerus Signed-off-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260906131942.83153-2-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit bf1dee2621857772d0455d9b4d97dd1dae069d70 Author: Marian Rotariu Date: Thu Aug 6 11:53:02 2026 +0300 usb: typec: tipd: don't send GAID when probe fails in APP mode commit c5df31f10880737d13b75eff42faee7accb9f956 upstream. When probe fails after the chip was already in APP mode (booted from EEPROM), the err_reset_controller path unconditionally calls tps->data->reset(), which for tps25750 sends the GAID 4CC command. GAID transitions the chip from APP back to PTCH, causing a second probe attempt that sees PTCH mode and tries to load the firmware from /lib/firmware, instead of reading the EEPROM as it should. The err_reset_controller path can be triggered by -EPROBE_DEFER from the probe sequence. GAID should only be sent when the controller actually loaded firmware at probe time. The abnormal behavior was seen on a tps25751d that has an EEPROM connected to it. Fixes: d49f90822015 ("usb: typec: tipd: add init and reset functions to tipd_data") Cc: stable Signed-off-by: Marian Rotariu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260806085302.1307606-1-marian.c.rotariu@gmail.com Signed-off-by: Greg Kroah-Hartman commit 184d842121e7d1fbc3a81895f36f72fa27444163 Author: Amit Sunil Dhamne Date: Thu Sep 3 00:22:21 2026 +0000 usb: typec: tcpm: recover after failure to start the frs ams commit 90156585765b29304f07b0e4a1c56a969876fcfc upstream. Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by initiating error recovery on it. This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state. Log snippet before changes: [ 101.401960] AMS FAST_ROLE_SWAP start [ 101.401971] Sink TX No Go [ 101.401982] sourcing vbus [ 101.401987] VBUS on [ 101.402159] VBUS on [ 109.257809] CC1: 0 -> 0, CC2: 5 -> 0 [state SNK_READY, polarity 1, disconnected] [ 111.267442] VBUS on After changes: [ 70.541211] AMS FAST_ROLE_SWAP start [ 70.541220] Sink TX No Go [ 70.541228] state change SNK_READY -> ERROR_RECOVERY [rev3 NONE_AMS] [ 70.541362] VBUS on [ 70.541365] sourcing vbus [ 70.541367] VBUS on [ 70.541374] state change ERROR_RECOVERY -> PORT_RESET [rev3 NONE_AMS] [ 70.541410] disable vbus discharge ret:0 [ 70.543028] Setting usb_comm capable false [ 70.544009] Setting voltage/current limit 0 mV 0 mA [ 70.544034] polarity 0 [ 70.544239] Requesting mux state 0, usb-role 0, orientation 0 [ 70.555550] cc:=0 [ 70.555595] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [ 70.555697] VBUS off [ 70.555702] VBUS VSAFE0V [ 70.555762] CC1: 5 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 70.587794] VBUS off [ 70.587799] VBUS VSAFE0V [ 70.655672] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 70.655682] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev3 NONE_AMS] [ 70.655686] Start toggling [ 70.656274] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] Fixes: 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance") Cc: stable Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260903-frs-error-handling-v1-1-ad0fee541847@google.com Signed-off-by: Greg Kroah-Hartman commit 7a9f61476b0e8002092a52ee8295edeeb0a28d1e Author: Hui Peng Date: Sun Sep 20 23:17:02 2026 +0000 usb: core: clear both ep_in and ep_out for non-ep0 control endpoints commit 0e8baa78d872f2db440d8b9ded946ab8dceb89eb upstream. In usb_enable_endpoint(), non-zero control endpoints (where usb_endpoint_xfer_control(&ep->desc) is true) populate both dev->ep_in[epnum] and dev->ep_out[epnum] with the same struct usb_host_endpoint pointer. However, usb_disable_endpoint() only clears either dev->ep_out[epnum] or dev->ep_in[epnum] depending on the direction bit of epaddr when reset_hardware is set, leaving the opposite direction's array slot pointing to the disabled/freed endpoint. Clear both dev->ep_out[epnum] and dev->ep_in[epnum] when disabling a non-ep0 control endpoint with reset_hardware set, and update the function kerneldoc accordingly. Tested in QEMU against Linux 7.3.0-rc3 using dummy_hcd and raw-gadget to enumerate a USB device with a non-zero control endpoint (bEndpointAddress 0x01, bmAttributes USB_ENDPOINT_XFER_CONTROL), verifying that both dev->ep_in[1] and dev->ep_out[1] are cleared when the interface is disabled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Assisted-by: LLM Signed-off-by: Hui Peng Acked-by: Alan Stern Link: https://patch.msgid.link/20260920231702.110963-1-benquike@gmail.com Signed-off-by: Greg Kroah-Hartman commit 63bb452e3de3de045ebe9c8c1037cd00ad507f32 Author: Myeonghun Pak Date: Sun Sep 13 00:10:33 2026 -0400 usb: chipidea: tegra: disable runtime PM on resume failure commit f1d6f7d25fe88ee49aaad96c8649e090fc3a4b68 upstream. tegra_usb_probe() enables runtime PM before resuming the device. If pm_runtime_resume_and_get() fails, probe returns without disabling runtime PM. The later error paths reach pm_runtime_force_suspend(), but this early return bypasses that cleanup. Disable runtime PM before returning the resume error. Do not use the fail_power_off path: the failed resume did not retain a usage reference, so its pm_runtime_put_sync_suspend() would be unbalanced. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 8b85e11c1a7a ("usb: chipidea: tegra: Add runtime PM and OPP support") Cc: stable Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Peter Chen Link: https://patch.msgid.link/20260913041033.25144-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9d8761b3c133f6c6a6d3486839dac60e2cf4bfe3 Author: Yuchao Zhang Date: Fri Sep 18 08:54:38 2026 +0800 usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC commit 9cd072788c76595529eb38f42bf94d23852f8534 upstream. When user space sets up FunctionFS with only full-speed descriptors (e.g., flags = FUNCTIONFS_HAS_FS_DESC) and the gadget operates at a higher speed (such as USB_SPEED_HIGH or USB_SPEED_SUPER), config_ep_by_speed() detects that the function lacks descriptors for the current speed, logs a warning, and falls back to full-speed descriptors. The endpoint is then successfully enabled via usb_ep_enable(), and epfile->ep becomes valid. However, when user space subsequently issues the FUNCTIONFS_ENDPOINT_DESC ioctl to query the endpoint descriptor, ffs_epfile_ioctl() selects the descriptor index solely based on gadget->speed: switch (epfile->ffs->gadget->speed) { case USB_SPEED_SUPER: case USB_SPEED_SUPER_PLUS: desc_idx = 2; break; case USB_SPEED_HIGH: desc_idx = 1; break; default: desc_idx = 0; } desc = epfile->ep->descs[desc_idx]; memcpy(&desc1, desc, desc->bLength); Because user space only supplied full-speed descriptors, epfile->ep->descs[1] is NULL. Dereferencing desc->bLength triggers an immediate kernel NULL pointer dereference panic. Fix this by falling back through lower speed descriptors if the current speed descriptor was not supplied, matching the fallback logic in config_ep_by_speed() and historical f_fs behavior. If still missing, fall back to epfile->ep->ep->desc (the active descriptor), and return -EINVAL safely if no valid descriptor is found. In addition, mark desc as const to match struct usb_ep::desc and avoid discarding qualifiers. Fixes: c559a3534109 ("usb: gadget: f_fs: add ioctl returning ep descriptor") Cc: stable@kernel.org Signed-off-by: Yuchao Zhang Acked-by: Michał Nazarewicz Link: https://patch.msgid.link/20260918005438.81263-2-ndaugoing@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7ce4dca0d53b1c3cb2b7e7bb2e42bf5db860caf2 Author: Alan Stern Date: Sun Sep 20 17:37:34 2026 -0400 USB: gadget: dummy-hcd: Fix wait for outstanding request completions commit b263ff9b0fc5c1f371d65c4eb196b31263d039ff upstream. The dummy-hcd driver emulates synchronize_irq() by waiting until its private callback_usage counter drops to 0 (with the private lock not held). This counter is incremented whenever a gadget driver callback occurs (which requires the private lock to be dropped), but not when a request completion handler is called. This is an oversight. Request completion is triggered by timer interrupts (emulating device IRQs in a real UDC), and the interrupt handlers are supposed to have completed when the synchronize_irq() emulation routine returns -- they aren't supposed to be in the middle of a completion callback. If this happens it can lead to a gadget driver's unbind routine running before all outstanding request completions have finished, maybe even allowing the gadget driver's module to be unloaded while a completion handler is still running. Fix the oversight by incrementing the callback_usage value across request completion callbacks. Link: https://lore.kernel.org/linux-usb/7a87e293-633c-4100-aa8d-91560ba5e5c5@rowland.harvard.edu/ Fixes: 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change") Tested-by: Minseo Kim Signed-off-by: Alan Stern Cc: stable Link: https://patch.msgid.link/f23b9e1a-f110-441a-a1d8-95f442ec09d5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit f343bfa3fc9f6255602d66f4a7dbe7ddef13ba41 Author: Fan Wu Date: Tue Sep 8 04:17:39 2026 +0000 usb: gadget: aspeed-vhub: cancel wake work on device removal commit 20388c8d1d74c203fec8194c45cd31afdfab934e upstream. wake_work is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in ast_vhub_remove(), so a work item queued before or during removal can run after devm has freed vhub and its ports, a use-after-free. Cancelling the work alone is not sufficient: usb_gadget_wakeup() takes no lock and the unbind path never clears wakeup_en, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed. ast_vhub_del_dev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d->registered is clear: the check and the schedule_work() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancel_work_sync() after the del_dev loop, and one that arrives later returns without arming. Also move INIT_WORK() to the top of ast_vhub_probe(), since the probe error path reuses ast_vhub_remove() and would otherwise cancel a never-initialized work item. This issue was found by an in-house static analysis tool. Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Benjamin Herrenschmidt Link: https://patch.msgid.link/20260908041740.613713-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 0f48945e53f4b0d3b807baad643bb2eb9a921678 Author: Radhey Shyam Pandey Date: Wed Sep 2 20:24:04 2026 +0530 usb: dwc3: am62: Fix runtime PM usage count leak on probe error path commit 3d9bbf0ffeb9b7ac1b6ad06b52e037870a7e0c63 upstream. dwc3_ti_probe() takes a runtime PM reference with pm_runtime_get_noresume() before creating the dwc3 core child device, and releases it with pm_runtime_put_autosuspend() once probe has succeeded. The err_pm_disable error path only disables runtime PM, so the reference taken a few lines earlier is never dropped. The usage counter lives in struct device and is not reset when the driver is unbound, so the leaked reference outlives the failed probe. If the device is probed again, through a manual rebind or a module reload, the counter starts at one instead of zero and the pm_runtime_put_autosuspend() on the success path can no longer bring it back down. The wrapper then stays runtime resumed for good and autosuspend never kicks in. Drop the reference before disabling runtime PM, matching the ordering already used in dwc3_ti_remove(). Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver") Cc: stable Assisted-by: Claude:claude-opus-5 Signed-off-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260902-dwc3-am62-rpm-fix-v1-1-7a2807e33307@amd.com Signed-off-by: Greg Kroah-Hartman commit 675056e0edb49c0002ebfbc289e6c777bbf315a2 Author: Linkai Gong Date: Thu Sep 10 09:11:50 2026 +0800 usb: typec: anx7411 - stop the IRQ before destroying the workqueue commit 469600d5d292b1482c90dd6853555821d11b8c5f upstream. The IRQ is devm-managed, so it can still queue plat->work while remove() is tearing the queue down. Disable it first. Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support") Cc: stable Signed-off-by: Linkai Gong Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260910011150.2966843-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 36f3f009049bc91e14dc856007932473318d12f8 Author: Liu Chao Date: Mon Sep 21 15:25:51 2026 +0800 usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd commit 9062d50e75c24dc7911be05c9b1719b3b256af15 upstream. generic_set_cmd() and generic_get_cmd() use the low nibble of ctrl->bRequest as an index into con->data[]: u8 cmd = (ctrl->bRequest & 0x0F); /* 0 .. 15 */ ... con->data[cmd] = value; /* OOB when cmd >= 5 */ struct usb_audio_control (include/linux/usb/audio.h) declares data as a 5-element array, so indices 5 through 15 write (or read) up to 44 bytes past the end of the array on the heap. A malicious USB host can craft a class-specific SET_CUR / GET_CUR request with an arbitrary bRequest value, triggering the out-of-bounds access from an IRQ completion handler with no further preconditions. Add an ARRAY_SIZE() guard to both functions. Fixes: c47d7b09891a ("USB: audio: add USB audio class definitions") Cc: stable Reviewed-by: Weibin Liu Signed-off-by: Liu Chao Reviewed-by: Ivy Lopez Link: https://patch.msgid.link/20260921072551.3708191-1-liuc63@xiaopeng.com Signed-off-by: Greg Kroah-Hartman commit 8294ff75a9de23f7cc641e5e5ca31fa6ea72a574 Author: Takashi Iwai Date: Tue Sep 1 16:52:46 2026 +0200 usb: gadget: midi2: Fix the jack descriptor array sizes commit 310c2d4608d8c1a2baa57db1dfd319c5c40cf4a1 upstream. The jack in/out descriptor arrays in struct f_midi2_usb_config have the size of MAX_CABLES, which look reasonable -- but it turned out to be incorrect. Namely, the entries for those arrays are added from both inputs and outputs, hence for each loop cycle, it adds two, ended up with as twice as the expected size. This inconsistency may result in potential OOB when a large number of jacks are set up via configfs, although the max number of cables (the loop count) is limited to MAX_CABLES. For addressing it, correct the jack_ins & jack_outs array sizes to twice, MAX_CABLES * 2. Fixes: 856fa444b098 ("usb: gadget: midi2: Dynamically create MIDI 1.0 altset descriptors") Cc: stable Reported-by: syzbot+c35f34092a4bc9855be6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c35f34092a4bc9855be6 Link: https://lore.kernel.org/20260826134606.127250-1-eadavis@sina.com Cc: Edward Adam Davis Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260901145512.785142-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 2b3931d8272fd438f2d8a7f6f01881792a61947d Author: Myeonghun Pak Date: Mon Sep 14 21:20:11 2026 -0400 usb: ohci-st: disable controller wakeup on removal commit 08b2ccd7eb7e41f77a04a09112ca3edcc588e3f0 upstream. Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: d115837259ad ("usb: host: ohci-st: Add OHCI driver support for ST STB devices") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Patrice Chotard Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-5-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7f3ad92e69fa9a6b77ab26af59f1ccbcbfb2eb1e Author: Myeonghun Pak Date: Mon Sep 14 21:20:09 2026 -0400 usb: ohci-s3c2410: disable controller wakeup on removal commit 8dd8451c527e2a723bca20da5a6d724b8592551f upstream. Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-3-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit b0fed527090733e9b108c242f24a392dbeb0ff48 Author: Myeonghun Pak Date: Mon Sep 14 21:20:08 2026 -0400 usb: ohci-da8xx: disable controller wakeup on cleanup commit 901197dd4c7dcffbf97426487d4c047555c98554 upstream. The OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Probe enables wakeup, but neither removal nor a later notifier registration failure disables it, leaving the wakeup source attached. Disable controller wakeup after removing the HCD on both paths. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-2-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 990f1241bb1b6273391b574d9d7b69e39d763930 Author: Orgad Shaneh Date: Tue Sep 1 19:30:27 2026 +0000 usb: octeon-hcd: fix the FIFO-flush timeout computation commit 4c7a1b9f1f1979f2b3b69428ada12680695159c2 upstream. cvmx_wait_tx_rx() computes its 100us deadline from (u64)octeon_get_clock_rate - the address of the function, not its return value; the parentheses have been missing since the CVMX_WAIT_FOR_FIELD32 macro became a function. The cast makes it compile silently, and the resulting deadline is effectively infinite. On a healthy controller the flush bit clears on the first read and nothing is noticed. On a controller whose PHY did not come up (for example when the reference-clock configuration is wrong for the board), txfflsh/rxfflsh never clear and probe spins forever in __delay() - observed as a hard hang with a soft-lockup splat on a CN5020 board, where the board watchdog then resets the system with no console output. Call the function, restoring the 100us timeout the code always intended. Fixes: 3e195a80e096 ("Staging: octeon-usb: Replaces CVMX_WAIT_FOR_FIELD32 macro with a function") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20260901193100.1352110-1-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2dc82d6a12050c2c678a328cd29837beb367df7d Author: Lovekesh Solanki Date: Thu Sep 3 16:59:03 2026 +0530 usb: hub: use shorter 120ms post resume hold for SS root hubs commit 29480b05e6e226594dc11ccf2a036fbd5cdd0e42 upstream. Holding a USB3 hub PM runtime reference for 200ms at hub resume triggers an AMD platform issue. Users running Android adb report crashes after adb has been polling and waking up the USB subsystem once a second for some time. Vendors are working on a solution. Disabling USB runtime PM is one way to prevent this issue, but it is also proven that reducing the hold time to 120ms in resume also mitigates it. See Link for more details. Reducing the hold time to 120ms for the USB3 roothub is in itself a valid change and optimization, as the current 200ms is excessive: a root hub has no upstream suspended hub whose wake propagation needs to be accounted for, but still need some time for USB3 link training to complete. Keep the 200ms hold for external hubs that commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") is intended for. Reported-by: Mathieu Fluhr Link: https://lore.kernel.org/all/CAPyJwA_D9qw0T72f8zwM1yKjP+To=maVANbcdsWM7yRmbBxYvw@mail.gmail.com/ Cc: stable Fixes: 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") Signed-off-by: Lovekesh Solanki Acked-by: Mathias Nyman Link: https://patch.msgid.link/20260903112903.542719-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit c85e8331d298b8f1dee8fe63718e76435cec7133 Author: Syed Labeeq Sajid Bukhari Date: Thu Sep 10 19:03:43 2026 +0500 usb: storage: sierra_ms: reject short SWoC info transfers commit 8a0200d14acd9db388b85cd016e68a4e60d900ec upstream. sierra_get_swoc_info() requests sizeof(struct swoc_info) (60) bytes from the device via usb_control_msg(), but its callers only treat a negative return value as failure. A device that answers the vendor-specific GetSwocInfo request with a short IN transfer is therefore accepted, leaving the tail of the freshly allocated (kmalloc(), non-zeroing) swoc_info buffer uninitialized. truinst_show() subsequently prints swocInfo->rev, swocInfo->LinuxSKU and swocInfo->LinuxVer from that buffer into the world-readable (0444) "truinst" sysfs attribute. An emulated/malicious USB device (VID 0x1199, PID 0x0fff) can exploit this to disclose up to 5 bytes of stale kernel heap memory (kmalloc-64) to unprivileged userspace, once per sysfs read, indefinitely. On kernels built without init_on_alloc this leaks recently freed heap contents. Only accept the transfer when the full structure was received. sierra_ms_init() already retries failed queries, so well-behaved devices are unaffected. Fixes: 32fe5e393455 ("USB Storage Sierra: TRU-Install feature update") Cc: stable Signed-off-by: Syed Labeeq Sajid Bukhari Assisted-by: Kimi:K2 [Kimi Code CLI] Link: https://patch.msgid.link/20260910140343.49371-1-syedlabeeq@gmail.com Signed-off-by: Greg Kroah-Hartman commit 60cc9379c3e650d1ebfba4de63f1242537a62a32 Author: Johan Hovold Date: Fri Aug 21 17:45:43 2026 +0200 USB: serial: fix port tear down use-after-free commit 33c920f7c5952dfc42d1b8ea6efe16b1f0bb0c5b upstream. Some drivers for multiport devices access port driver data from completion handlers of shared URBs submitted at attach() or first open() and stopped at disconnect() or last close(), respectively. A simple NULL check before accessing the driver data makes sure that a port state container has at least been allocated, but a completion handler can still race with port tear down. Reorder the disconnect handling so that ports are not deregistered (and their driver data freed) until after all ports have been hung up and the driver disconnect() callback has run so that all I/O has been stopped. Fixes: 2d93148ab698 ("USB: serial: fix lifetime and locking problems") Reported-by: syzbot+e5e28c3e953b2eebb16e@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a7e6fb9.ec5dc6cc.21cb3f.00c0.GAE@google.com/ Cc: stable@vger.kernel.org # 2.6.30 Cc: Alan Stern Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9742905d9ed5bf23ebe4c100dec80b6bc50fb522 Author: Yuchao Zhang Date: Fri Sep 18 19:43:09 2026 +0800 USB: cdc-acm: skip URB restart in port_shutdown if disconnected commit dc614d6bc991740d41d5a99ac7765c4b675dda88 upstream. acm_port_shutdown() is called from the tty-port machinery whenever the last user closes the port. acm_disconnect() sets acm->disconnected and calls tty_port_tty_vhangup(), which eventually triggers port_shutdown(). At that point acm_disconnect() has already called acm_poison_urbs() and is about to free the control and read URBs. However, acm_port_shutdown() unconditionally calls acm_unpoison_urbs() and, when the ALWAYS_POLL_CTRL quirk is set, immediately re-submits the ctrlurb and all read URBs. If the concurrent acm_disconnect() then frees those URBs and their DMA buffers while they are in-flight, the result is a use-after-free in acm_ctrl_irq() or acm_read_bulk_callback() accessing the freed DMA memory. Fix by checking acm->disconnected after draining the delayed anchor and returning early: if we are in a disconnect path the URBs must remain poisoned and must not be resubmitted. The early return is placed after the delayed-anchor drain loop because that loop only cancels write-side accounting (wb->use = false and autopm counter) and does not touch the hardware path. Fixes: f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen") Cc: stable Signed-off-by: Yuchao Zhang Link: https://patch.msgid.link/20260918114309.3659635-2-ndaugoing@gmail.com Signed-off-by: Greg Kroah-Hartman commit 13690b86155edfd4d1a0e2da3cb38bc41fdbad41 Author: Johan Hovold Date: Mon Sep 7 11:51:30 2026 +0200 USB: cdc-acm: fix racy TIOCMIWAIT implementation commit be4219dd98608736e13e0b790ef742b76a13254d upstream. Check the wakeup condition after adding the task to the waitqueue and updating the task state to avoid missing a racing modem status update or disconnect. Store the old icount on entry and do not update it in the completion handler to avoid missing events or reporting spurious ones (due to modem status changes before TIOCMIWAIT was called). Fixes: 5a6a62bdb925 ("cdc-acm: add TIOCMIWAIT") Cc: stable Cc: Oliver Neukum Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907095130.130636-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3c04e15dda0c312b2c5b064cfe8813b2860e8acf Author: Viken Dadhaniya Date: Tue Sep 15 18:56:27 2026 +0530 soc: qcom: geni-se: Correct QUP Core ICC vote constants commit 1cd9b1be5a9c56fd69e3f555b200a1844f9b873e upstream. The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their values are several orders of magnitude too small. For example, the 50 MHz threshold is represented by 2500 rather than 25000000 Bps. As a result, clients using these constants can severely under-vote the QUP Core clock. Correct the constants to their intended Bps thresholds so that the ICC provider selects the corresponding QUP Core 2X clock rate. Drop the unused definitions. Fixes: 58ffbba6a399 ("soc: qcom: geni: Support for ICC voting") Cc: stable@kernel.org Signed-off-by: Viken Dadhaniya Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-1-f78eb611204e@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 466041d14f26dc2babd606a2e85dce08774112a6 Author: Yuxiao Wang Date: Wed Sep 9 12:44:00 2026 +0000 nitro_enclaves: fix use-after-free on SLOT_ALLOC failure commit 9bc184a2eda8b773c88ecbff934001ad649b9cc1 upstream. When ne_create_vm_ioctl() fails the SLOT_ALLOC request after anon_inode_getfile() has succeeded, the error path calls fput(enclave_file) and then frees ne_enclave. In normal userspace context, fput() defers the final __fput() via task_work. ne_enclave_release() therefore runs after ne_enclave has already been freed and dereferences ne_enclave->slot_uid, causing a use-after-free: KASAN: slab-use-after-free in ne_enclave_release. The enclave has no slot allocated and is not yet linked into the enclaves list on this error path, so ne_enclave_release() is expected to return early when slot_uid is zero. However, reading slot_uid already accesses the freed object. Clear enclave_file->private_data before fput() on the error path. ne_enclave_release() then returns immediately when private_data is NULL, leaving the ioctl error path as the sole owner of ne_enclave. This is safe because the file has not been fd_install()'d yet. Tested on an AWS EC2 m5.2xlarge with CONFIG_KASAN=y. Without the patch, the reproducer triggers a KASAN slab-use-after-free on every SLOT_ALLOC failure. With the patch, no KASAN report is produced and the SLOT_ALLOC error is still returned. Normal enclave creation and teardown are unaffected. Fixes: 9c8eb50fe9e2 ("nitro_enclaves: Add logic for terminating an enclave") Cc: stable@vger.kernel.org Co-developed-by: Zhaofeng Chen Signed-off-by: Zhaofeng Chen Signed-off-by: Yuxiao Wang Reviewed-by: Alexander Graf Link: https://patch.msgid.link/20260909124400.27857-1-graf@amazon.com Signed-off-by: Greg Kroah-Hartman commit 7c370756e8851346049821effe68b5cf740006e2 Author: Raphaël Larocque Date: Sat Sep 26 20:58:10 2026 -0400 Input: synaptics - limit T440p InterTouch quirk to LEN0036 commit f0fd8993082ca229faa3f9844f1c9fe182eca20b upstream. The ThinkPad L440 also uses board id 2722, but does not have the SMBus initialization problem seen on the T440p. On the L440, the SMBus companion becomes available shortly after psmouse probes, allowing the touchpad to use SMBus/RMI4 normally. The T440p's quirk is currently applied to all Synaptics touchpads with board id 2722, unnecessarily disabling SMBus InterTouch on the L440, as reported by Daniel Salmun. Restrict the quirk to PNP ID LEN0036, which identifies the T440p, so that other devices sharing board id 2722 retain their normal SMBus/RMI4 operation. Reported-by: Daniel Salmun Link: https://lore.kernel.org/all/20260925230039.236786-1-salmundani@gmail.com/ Fixes: 26eb3d92c7a4 ("Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)") Cc: stable@vger.kernel.org Signed-off-by: Raphaël Larocque Link: https://patch.msgid.link/20260927005810.85971-1-rlarocque@disroot.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 655fc233f9ce8972a8bc9321d9da7a8aec7512fa Author: Lovekesh Solanki Date: Mon Sep 21 01:37:30 2026 +0530 Input: synaptics - add LEN205b entry to smbus_pnp_ids for ThinkPad T490 commit a961417c5ae77bbb728a23d9577ecd8f4d8a4b5a upstream. Lenovo ThinkPad T490 has a Synaptics Touchpad that supports SMBus/RMI4 mode, but is not listed in smbus_pnp_ids table. Add LEN205b to smbus_pnp_ids[] passlist. Reported-by: John Rosencutter Closes: https://lore.kernel.org/all/CAOGuaRh025eKcBf9P8UrvtXNp68vQ0HVF2EbNMp-kpdaC1HNpA@mail.gmail.com/ Signed-off-by: Lovekesh Solanki Link: https://patch.msgid.link/20260920200730.1836756-1-lovekeshsolanki00@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b034424d3488103d49b2b9d54c308636b98ae881 Author: David Heidelberg Date: Sat Sep 26 22:26:47 2026 +0200 Input: s6sy761 - fix resume ordering and restore sensing commit a215720959c5450b3699e243904b39c3f8f68888 upstream. System suspend powers the controller off and resume powers it back on, but the resume path enables the interrupt before s6sy761_power_on() checks the boot. The firmware raises its boot-complete event on the interrupt line, the threaded handler consumes it, s6sy761_power_on() then reads an empty event and resume fails with -ENODEV, skipping the touch function setup: s6sy761 2-0048: PM: dpm_run_callback(): s6sy761_resume [s6sy761] returns -19 Power the chip on first and only then unmask the interrupt. Once resume completes the boot handshake the chip comes back with sensing off, as at probe where input_open() turns it on, so the touchscreen stays dead after resume. Send SENSE_ON again when the input device is open. Tested on a Pixel 3 XL over several s2idle cycles: resume succeeds and the touch function and sense status match the pre-suspend state. Assisted-by: LLM Cc: stable@vger.kernel.org Fixes: 0145a7141e59 ("Input: add support for the Samsung S6SY761 touchscreen") Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260926-s6sy761-suspend-v2-1-8f00a96ee6e8@ixit.cz Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 868ea952d23eeac2097d31872a77e152d2593e25 Author: Lovekesh Solanki Date: Sun Sep 20 17:05:41 2026 +0530 Input: i8042 - add nomux quirk for Fujitsu LIFEBOOK U7410 commit 495cd7f858b45d2ffa9b685bba3a8c23c1ca4dd3 upstream. On the Fujitsu LIFEBOOK U7410 the internal keyboard and touchpad die shortly after boot if i8042 multiplexing controller is probed and switched to muxed mode. These multiplexing setup commands disturb the EC emulated keyboard and atkbd reports "Spurious ACK" and "Unknown key pressed" warnings, after which both keyboard and touchpad stop delivering events. Both touchpad and keyboard work in BIOS and GRUB. Disabling multiplexer using i8042.nomux=1 makes both devices work on warm/cold boot. Add a DMI quirk to force nomux mode for this model. Reported-by: Heiko Brey Link: https://lore.kernel.org/all/89f36f3f5e4c2d07b9ff72bc0b355875c336e498.camel@gmx.de/ Signed-off-by: Lovekesh Solanki Link: https://patch.msgid.link/20260920113541.1484808-1-lovekeshsolanki00@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a562f6c0ab39adfceeed7f48bdf3ea1206ccad3d Author: Martino Papero Date: Wed Sep 30 22:10:41 2026 +0200 Input: atkbd - skip deactivate for Lenovo IdeaPad Slim 3 15IWC11 commit 3bf8d603fd45649c106cae6290a10f20b1bbb569 upstream. The internal keyboard on the Lenovo IdeaPad Slim 3 15IWC11 (83RR) does not work correctly with the default i8042 settings. Using i8042.nopnp=1 and i8042.dumbkbd=1 restores keyboard input, but prevents the Caps Lock LED from working. Using i8042.nopnp=1 alone does not fix the keyboard. The laptop works correctly when atkbd_deactivate_fixup is used instead. Add a DMI quirk for the 83RR to enable it. This was tested without any i8042 command-line parameters. Keyboard input and the Caps Lock LED work correctly, including after suspend and resume and after a cold boot. Link: https://lore.kernel.org/all/4f43465f-98ba-4722-8e29-03df20315369@kernel.org/ Signed-off-by: Martino Papero Reviewed-by: Hans de Goede Link: https://patch.msgid.link/c0b597b8-e7ad-4fba-a2bb-5d252e3dfbd3@lcb.to.it Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7996f245cd7006c5aa2de957998f300ededa6c5d Author: Wentao Liang Date: Thu Sep 17 15:55:23 2026 +0000 kgdboc: Fix tty driver reference leak in configure_kgdboc() commit ef3134cd0d4831ae2137aee2883987859b80b2c6 upstream. tty_find_polling_driver() returns the tty driver with an extra reference taken by tty_driver_kref_get(). configure_kgdboc() stores it in kgdb_tty_driver but the reference is never dropped: it is leaked when kgdb_register_io_module() fails, when the configuration is cleared, and on every reconfigure. Release the reference both when unconfiguring and on the error path. Fixes: 7d7b93c1452f ("tty: kref the tty driver object") Cc: stable@kernel.org Signed-off-by: Wentao Liang Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20260917155523.2161202-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 7fd609fb0e9dcbc4d7a1e4da1af5368c0555ff55 Author: Tomer Pomeranc Date: Wed Aug 12 22:53:15 2026 +0300 binder: fix leaked fd fixups on TF_UPDATE_TXN supersede commit c4c02084d6687d5cd5edccaf52cc45e5160f1184 upstream. When a TF_UPDATE_TXN transaction supersedes a pending async transaction in a frozen process, the outdated transaction is freed with kfree() directly. This skips binder_free_txn_fixups(), leaking all binder_txn_fd_fixup entries and their fget()'d struct file references. The leaked file refcounts never reach zero, so the struct file objects are permanently pinned in memory. They survive process exit and accumulate across invocations until file-max exhaustion. Every other transaction cleanup path (binder_free_transaction(), binder_transaction() error paths, binder_release_work()) correctly calls binder_free_txn_fixups(). Add the missing call before kfree() in the t_outdated cleanup block. Fixes: 9864bb480133 ("Binder: add TF_UPDATE_TXN to replace outdated txn") Cc: stable Signed-off-by: Tomer Pomeranc Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260812195316.259136-2-tomerpo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 60a9f7323ae7318a7cce0d387c318da24f1e8726 Author: Tomer Pomeranc Date: Wed Aug 12 22:53:16 2026 +0300 binder: fix is_failure flag for superseded transaction cleanup commit 22c135635fdd9816c0ef140d6de7b2e4fdf73e89 upstream. When a TF_UPDATE_TXN transaction supersedes a pending async transaction, binder_release_entire_buffer() is called with is_failure=false. Since the superseded transaction was never delivered, binder_apply_fd_fixups() was never called and no fds were installed in the target process. With is_failure=false, the BINDER_TYPE_FDA cleanup handler interprets stale buffer contents as installed fd numbers and passes them to binder_deferred_fd_close(), closing unrelated file descriptors. Pass is_failure=true since the transaction was never delivered to the target, matching the semantics of all other undelivered-transaction cleanup paths. Fixes: 9864bb480133 ("Binder: add TF_UPDATE_TXN to replace outdated txn") Cc: stable Signed-off-by: Tomer Pomeranc Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260812195316.259136-3-tomerpo@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2b9a53940a2bc063ea4cd09ee49220a503a0170c Author: Guangshuo Li Date: Mon Sep 21 18:33:18 2026 +0800 drm/amdgpu: fix ACP MFD device leak on init failure commit f0013046151b7467e62c471c1c83d63ea255799c upstream. acp_hw_init() registers ACP child devices with mfd_add_devices() before attaching them to the ACP power domain and initializing the hardware. If attaching a child to the power domain fails, or if the ACP reset or clock enable operation times out, the failure path frees only the source cell, resource, and platform-data allocations. The child platform devices already registered by mfd_add_devices() remain registered and are never released. Remove the children from the power domain and unregister the MFD devices on failures that occur after mfd_add_devices() succeeds. Keep mfd_add_devices() failures on the existing cleanup path since the MFD core already rolls back partially registered children itself. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks") Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 63da68d6a2279ec945581c990c5a59a5ae8b5560) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0563b26c1437fe7e25ea42c334eb85c0a703f8ff Author: Guangshuo Li Date: Sun Sep 20 00:55:11 2026 +0800 drm/amdgpu: fix IP instance memory leak on kobject add failure commit f5a5add3605935163dd0f75749b6a7869e9765af upstream. amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with kzalloc_flex() and initializes its embedded kobject before calling kobject_add(). If kobject_add() fails, the return value is ignored and execution continues without dropping the initial kobject reference. The failed kobject is not retained in the kset list, so the normal sysfs teardown path cannot find it. As a result, ip_hw_instance_release() is never called and the ip_hw_instance allocation is leaked. Call kobject_put() when kobject_add() fails so the initial reference is dropped and ip_hw_instance_release() can free the allocation. Keep the existing best-effort sysfs behavior by continuing with the remaining IP entries after the failed registration. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs") Reviewed-by: Lijo Lazar Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4a8f9cad0fced77b36b297c67c42730c9cb32ec6 Author: Wentao Liang Date: Wed Sep 16 17:40:58 2026 +0000 drm/mediatek: Fix pdev reference leak in mtk_drm_bind() commit 3753e34b73fcbe2a2edbe984614a008a261697ef upstream. When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174058.2088709-1-vulab@iscas.ac.cn/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 3d85bd738aba61df14dfaf8fe638e2172d8427bf Author: Guangshuo Li Date: Mon Sep 21 21:11:56 2026 +0800 drm/mediatek: Fix ovl adaptor platform device leak commit 048739be3e9cacae5301b68245668002fe6f0ce5 upstream. mtk_drm_probe() creates an OVL adaptor platform device with platform_device_register_data() when the display pipeline requires the OVL adaptor. If a later initialization step fails, the probe error path releases the DRM resources without unregistering the already registered OVL adaptor device. The normal remove path likewise leaves the device registered after the DRM driver is unbound. Keep track of whether the OVL adaptor was successfully registered and unregister it on probe failure. Also recover the platform device from the stored DDP component device and unregister it during normal removal. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260921131156.403652-1-lgs201920130244@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 4acac370aad2d4895a82f40b2f03e9ef70eecaa6 Author: Haojie Li Date: Tue Aug 25 18:08:45 2026 +0800 drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device commit bce7698e2e6565bb765bd0522337f29f5f312624 upstream. platform_device_register_data() can fail and return an ERR_PTR, but the return value is used without checking, leading to an invalid pointer being stored in ddp_comp[].dev and passed to component_match_add() and mtk_ddp_comp_init(), which could result in a kernel crash. Add an IS_ERR() check to jump to the error handling path on failure. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Haojie Li Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260825100845.438893-1-lihaojie@kylinos.cn/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit c14392adca9be45ff5a562c8510d565aab4346d7 Author: Imre Kaloz Date: Sun Sep 27 16:55:04 2026 +0200 drm/radeon: Read the VRAM VBIOS signature with readb() commit de1eab13efef83fd2b76f4688de5bf672644596f upstream. igp_read_bios_from_vram() checked bios[0]/bios[1] with a plain __iomem load, which faults on sparc64 before the copy runs at all. radeon_read_bios() already reads its two signature bytes with readb() ahead of its own copy; use the same accessor here, keeping the check before the allocation. Fixes: b442962a9e82 ("drm/radeon/kms: add support for "Surround View"") Signed-off-by: Imre Kaloz Signed-off-by: Alex Deucher (cherry picked from commit 09155b8932e5013dbce0f5cdff7d75264a279ee5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3a86ebf6aa8b0a845e6188daaa6f530fe67ff00e Author: Willian Oliveira Date: Mon Sep 21 22:54:10 2026 -0300 drm/amdgpu/gfx6: fix firmware leak on teardown commit cc172e177795c5f87bc2d71768d077e1c10633e8 upstream. The firmware requested in gfx_v6_0_init_microcode() is not released when the GFX block is torn down, leaking the firmware resources. Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini() to release the PFP, ME, CE and RLC firmware. Signed-off-by: Willian Oliveira Signed-off-by: Alex Deucher (cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 48157b3a8cacd6dcf5cffe944fb94882dfbf80f8 Author: Timur Kristóf Date: Wed Sep 23 14:03:54 2026 +0200 drm/amd/pm/si: Fix updating clock limits on AC/DC commit 08c9100f65299c64439e22e6057d750ae0e6c660 upstream. Assume that the AC limits are the maximum of all power states, and the DC limits are the maximum of battery power states. This shouldn't make any difference in practice, but is cleaner and more robust against bogus information in the VBIOS. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit ef8cb9dcc7db7b7abcbdbe870a080cc81e4f0bf3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a02501eb18519ba95d8c2cac028aaa6f4de051b1 Author: Timur Kristóf Date: Wed Sep 23 14:03:53 2026 +0200 drm/amd/pm/si: Check AMD_IS_MOBILITY flag for PPSMC_SYSTEMFLAG_GPIO_DC commit cd883d0a3937df82a5ea03709ba8ba623b868419 upstream. Unfortunately, some desktop boards eg. the FirePro D500 have the HARDWAREDC platform flag set and also have a battery power state configured in their VBIOS. This makes no sense for a desktop GPU and results in incorrect behaviour: the clocks are stuck at lowest. We observed that the kernel driver can work around the issue in two possible ways: 1. Set PPSMC_SWSTATE_FLAG_DC on all power states 2. Clear PPSMC_SYSTEMFLAG_GPIO_DC We think that the PPSMC_SYSTEMFLAG_GPIO_DC flag makes the SMC assume it's running on battery even though this is a desktop machine with no battery, and that's why it doesn't do DPM on power states without PPSMC_SYSTEMFLAG_GPIO_DC. Issue was uncovered by "Fix updating clock limits from power states" because previously the limits for the battery state were not tracked separately. However, battery power state has lower frequencies and voltages, so the kernel doesn't set the DC flag on the current power state anymore. That causes the SMC to be stuck on the lowest clocks. Let's clear PPSMC_SYSTEMFLAG_GPIO_DC on desktop GPUs. We can use the AMD_IS_MOBILITY flag to determine that. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16352 Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 58473c7c49ce9f5f5a4a1c24ffb9aa1d3c8771f4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 686baa1f4ec43b33e39e3d4b4a4539a91d17e883 Author: Jiangshan Yi Date: Fri Sep 4 17:18:17 2026 +0800 drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend commit 015e72cde567d2450e282c2790773463156b2d0a upstream. dc_state_create_copy() can return NULL on allocation failure. dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts() and continues execution, returning success. dm_resume() then dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the following dc_state->stream_count loop, crashing during GPU reset recovery. Return -ENOMEM immediately if the copy fails, so the caller aborts suspend instead of leaving a NULL cached state for resume. Fixes: 8092aa3ab8f7 ("drm/amd/display: Add null checker before passing variables") Reviewed-by: George Zhang Signed-off-by: Jiangshan Yi Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 84b6d7932fdd2857795a257f9f258562a3cddcab) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 967e7742cff1fa925eb2ae17bd8f5b0bd233b28a Author: Nikola Prica Date: Mon Sep 21 13:19:03 2026 +0200 PCI: Accept AtomicOps already enabled by the hypervisor [ Upstream commit 40cce45b921f7930886bcba43069edc579725457 ] pci_enable_atomic_ops_to_root() currently fails when no Root Port is visible. That is common in passthrough guests (ESXi, Hyper-V): the Endpoint is assigned to the VM, but the Root Port above it is not visible in the guest topology. In those setups the hypervisor may already have enabled AtomicOp Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set, treat AtomicOps as already enabled and return success instead of failing the Root Port walk. After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them"), pci_enable_atomic_ops_to_root() always returns failure if the Root Port is not visible, so drivers don't use atomics when they could. On systems where the Root Port is not visible but *does* support AtomicOps, this is a regression: prior to 1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned success. Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them") Signed-off-by: Nikola Prica [bhelgaas: commit log, code comment] Signed-off-by: Bjorn Helgaas Tested-by: Gerd Bayer Reviewed-by: Christian König Reviewed-by: Gerd Bayer Link: https://patch.msgid.link/20260921111903.978687-1-nikprica@amd.com Signed-off-by: Sasha Levin commit d938fcc78e3c9dfcbca02fad7b4b4e3efcc57812 Author: Takashi Iwai Date: Thu Oct 1 17:10:36 2026 +0200 ALSA: ice1712: Fix the error handling via auto-cleanup at probe [ Upstream commit e6229c0402ea4863ec74802d79d5b52b9398d66c ] We used the auto-cleanup via snd_card_unref() for errors at probe of ice1712 driver, but this may be problematic in a subtle way when an error happens at snd_card_register(); since snd_card_unref() skips the snd_card_disconnect() call, it may miss some resource clearance. For fixing the issue, use the new __free(snd_card_free) instead, which does call snd_card_free() explicitly at errors for avoiding such a pitfall. Fixes: d736eba9c453 ("ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup") Link: https://patch.msgid.link/20261001151039.592033-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 328b78ad6128b816e5c9de663d3c7c0231d1eba8 Author: Takashi Iwai Date: Thu Oct 1 17:10:35 2026 +0200 ALSA: core: Define auto-cleanup for snd_card_free() [ Upstream commit f1d565dc92955f05383794e0fa27e61ee0555027 ] For the errors at the probe time, we'd need to call rather snd_card_free() instead of the snd_card_unref() -- the former calls explicitly snd_card_disconnect() that cleans up the registered devices, etc, while the latter may leak in corner cases. For convenience, define a new auto-clean with snd_card_free. Link: https://patch.msgid.link/20261001151039.592033-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: e6229c0402ea ("ALSA: ice1712: Fix the error handling via auto-cleanup at probe") Signed-off-by: Sasha Levin commit 672b8a9ce8f51b991481dfde26fba5cc4340a91a Author: Luo Gengkun Date: Sun Sep 20 07:50:26 2026 +0000 perf: Fix race between perf_event_exit_task() and perf_pending_task() [ Upstream commit ffb684f2aa141eeb0caa6308422e7e05d1ded7c4 ] A race condition exists between perf_event_exit_task() and perf_pending_task() during begin_new_exec(). During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. So perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current). Since both task exit and exec paths can call perf_event_exit_task() which sets ctx->task to TASK_TOMBSTONE, fix this by explicitly checking if event->ctx->task equals TASK_TOMBSTONE and dropping the redundant PF_EXITING check. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Signed-off-by: Luo Gengkun Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260920075026.990582-1-luogengkun2@huawei.com Signed-off-by: Sasha Levin commit 0320fb393710c5aed0ccba58a843eecbaf7f1ab1 Author: Hongjian Dai Date: Wed Sep 30 00:43:40 2026 +0800 i2c: at91: release DMA channels when probe defers [ Upstream commit c98bf3b86609a18ab16d067280257326e557c636 ] at91_twi_probe_master() can return -EPROBE_DEFER from at91_init_twi_recovery_info() after at91_twi_configure_dma() has already claimed the tx/rx DMA channels. at91_twi_probe() then returns without releasing them, and since dma_request_chan() is not devres-managed the channels leak on every deferred probe attempt. Release the channels before deferring the probe. Fixes: f7eeb1af8537 ("i2c: at91: release DMA channels on remove and probe error") Assisted-by: LLM Signed-off-by: Hongjian Dai Signed-off-by: Andi Shyti Link: https://patch.msgid.link/7D85C6CB6BF0A82E+20260929164340.41628-1-daihongjian@kylinsec.com.cn Signed-off-by: Sasha Levin commit 3f6b5d81fc4bc6aa22bb1c62b66dbcd97392b1a2 Author: Lorenzo Bianconi Date: Tue Sep 29 15:43:03 2026 +0200 net: mvneta: clear XDP pfmemalloc flag between frames [ Upstream commit 8f1c2a10500a84a621ff13073f96deea0753ed42 ] mvneta_swbm_add_rx_fragment() sets XDP_FLAGS_FRAGS_PF_MEMALLOC on the xdp_buff when a fragment page is a pfmemalloc one (page under memory pressure). The xdp_buff is reused for the next frame, but only the XDP_FLAGS_HAS_FRAGS bit was cleared at frame start, so the pfmemalloc bit leaked from one frame into the following ones. mvneta_swbm_build_skb() propagates the flag to skb->pfmemalloc through xdp_update_skb_frags_info(), so the skb of a subsequent fragmented frame could be wrongly marked as pfmemalloc even if none of its pages are under pressure. Clear all the xdp_buff flags in mvneta_swbm_rx_frame(), which is invoked for each new frame, instead of just the XDP_FLAGS_HAS_FRAGS bit. Fixes: ed7a58cb40bd ("net: marvell: rely on xdp_update_skb_shared_info utility routine") Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260929-mvneta-xdp-clear-frag-fix-v4-1-1e63b25eeed8@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54edf06357a973fc2d8e15c9567e32c6fe3d3e58 Author: Alexander Lobakin Date: Tue Dec 3 18:37:26 2024 +0100 xdp, xsk: constify read-only arguments of some static inline helpers [ Upstream commit dcf3827cde8621d2317a7f98e069adbdc2112982 ] Lots of read-only helpers for &xdp_buff and &xdp_frame, such as getting the frame length, skb_shared_info etc., don't have their arguments marked with `const` for no reason. Add the missing annotations to leave less place for mistakes and more for optimization. Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Alexander Lobakin Link: https://patch.msgid.link/20241203173733.3181246-4-aleksander.lobakin@intel.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8f1c2a10500a ("net: mvneta: clear XDP pfmemalloc flag between frames") Signed-off-by: Sasha Levin commit 8fe3d6717f5536793727e60b7a0b7ec20c697def Author: Eric Dumazet Date: Mon Sep 28 19:45:24 2026 +0000 ipv6: sr: use skb_get_hash_net() in seg6_make_flowlabel() [ Upstream commit 8ec454dcd00ce3375119111c6394964455b36d0d ] Since commit d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") __skb_flow_dissect() needs a net pointer, either from skb->dev, skb->sk, or since commit 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect") a caller provided pointer. syzbot was able to reach seg6_make_flowlabel() with an skb having neither skb->dev nor skb->sk set: a TIPC UDP bearer sends a discovery message through an IPv4 route using seg6 encap, while net.ipv6.seg6_flowlabel is set to 1. seg6_make_flowlabel() already has a net pointer, use skb_get_hash_net(). WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0x910/0x5368 net/core/flow_dissector.c:1126, CPU#0: syz.0.17/4930 Call trace: __skb_flow_dissect+0x910/0x5368 net/core/flow_dissector.c:1126 (P) __skb_get_hash_net+0xe0/0x29c net/core/flow_dissector.c:1903 skb_get_hash include/linux/skbuff.h:1663 [inline] seg6_make_flowlabel+0xcc/0x1ec net/ipv6/seg6_iptunnel.c:132 __seg6_do_srh_encap+0x320/0xbf4 net/ipv6/seg6_iptunnel.c:161 seg6_do_srh+0x4b4/0xa44 net/ipv6/seg6_iptunnel.c:431 seg6_output_core+0x164/0x688 net/ipv6/seg6_iptunnel.c:681 seg6_output+0x44/0x1ac net/ipv6/seg6_iptunnel.c:744 lwtunnel_output+0x3d0/0x664 net/core/lwtunnel.c:356 dst_output include/net/dst.h:470 [inline] ip_local_out+0x110/0x148 net/ipv4/ip_output.c:131 iptunnel_xmit+0x50c/0xd38 net/ipv4/ip_tunnel_core.c:97 udp_tunnel_xmit_skb+0x220/0x348 net/ipv4/udp_tunnel_core.c:187 tipc_udp_xmit+0x75c/0x9c0 net/tipc/udp_media.c:202 tipc_udp_send_msg+0x214/0x374 net/tipc/udp_media.c:274 tipc_bearer_xmit_skb+0x260/0x3b0 net/tipc/bearer.c:576 tipc_enable_bearer net/tipc/bearer.c:366 [inline] __tipc_nl_bearer_enable+0xc90/0xfb0 net/tipc/bearer.c:1048 tipc_nl_bearer_enable+0x2c/0x48 net/tipc/bearer.c:1057 genl_family_rcv_msg_doit+0x1e4/0x2d4 net/netlink/genetlink.c:1114 Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Reported-by: syzbot+9408fbe0e6452a12e9ab@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6abac2eb.3654fce1.1bec97.0000.GAE@google.com/ Signed-off-by: Eric Dumazet Reviewed-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260928194524.3617299-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fce70b6bf9f3261e887419a4e7caa25b80fa9d55 Author: Prathamesh Deshpande Date: Sat Sep 26 17:53:57 2026 +0100 net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference [ Upstream commit 7b97273cbebe9dd4fddc457f0c4f2a124d0e3996 ] During XSK TX queue teardown, outstanding descriptors are completed without a CQE. If one requested a TX timestamp, the completion path passes that NULL CQE to mlx5e_xsk_fill_timestamp(), which dereferences it. Return zero when no CQE is available, indicating that teardown did not produce a TX timestamp. Fixes: ec706a860eba ("net/mlx5e: Implement AF_XDP TX timestamp and checksum offload") Signed-off-by: Prathamesh Deshpande Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260926165402.5902-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8bfbce926b97ac8ccb402b5fb6595661e5e4ea4b Author: Quentin Freimanis Date: Sun Sep 27 21:50:12 2026 -0700 net: sparx5: make ports inherit the switch base mac address type [ Upstream commit 5642b1648d5c4561d8ed7a410d0a7017f706604d ] When the switch uses a random base MAC address it does not mark each port's address as random: $ dmesg | grep "MAC addr" sparx5-switch e00c0000.switch: MAC addr was not set, use random MAC $ cat /sys/class/net/eth0/addr_assign_type 0 0 is NET_ADDR_PERM, so userspace thinks this is a stable address. With a random MAC reported as NET_ADDR_PERM, systemd's MACAddressPolicy=persistent [1] leaves it unchanged, so a DHCP client gets a new IP address every boot and a static reservation can't be used. Reporting it as NET_ADDR_RANDOM makes systemd replace it with a stable address derived from the interface name and machine-id. Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support") Signed-off-by: Quentin Freimanis Reviewed-by: Simon Horman Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20260928045012.30178-1-quentin@q-lab.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e4e737b2f1e8a55f51f11404fa8b06849f9aa94 Author: Harshit Mogalapalli Date: Thu Sep 24 23:39:36 2026 -0700 net: microchip: vcap: stop scanning after deleting key field [ Upstream commit 99b43ede9e355ba35244cc9470bf1819774ce39d ] The only call outside the KUnit tests is in sparx5_tc_add_rule_copy(), which passes a fixed key list with no duplicate entries. Therefore, the potential double-free is not currently reachable in tree. However, vcap_filter_rule_keys() is exported and does not require its key list entries to be unique. If a future or external caller supplies the same key at another position that the inner loop visits, it calls list_del() and kfree() a second time on the freed field, leading to a potential double-free. Break the inner loop after removing a matching field. The outer safe list traversal continues to process the remaining rule fields. Fixes: 465a38a269e9 ("net: microchip: sparx5: Support for copying and modifying rules in the API") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/ahs-lCAXXikkaHky@stanley.mountain/ Signed-off-by: Harshit Mogalapalli Reviewed-by: Daniel Machon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4d52b72f3aa68ad0536444e36530bda75070194c Author: Pablo Neira Ayuso Date: Wed Sep 23 10:53:02 2026 +0200 netfilter: flowtable: generalize pending status bit [ Upstream commit 7c549fb7eecd01fdba7c0d12c01da876ef8a3214 ] Rename NF_FLOW_HW_PENDING to NF_FLOW_PENDING and use it to inhibit the flowtable GC worker until pending hw offload work has been completed. Apparently, nf_flow_offload_stats() can schedule work to retrieve stats while the flow is being removed by GC. And this bit can also be used in a follow up patch to disable GC until the flow has been fully added in both directions. Revert the reordering done in commit d644b23afe1e ("netfilter: flowtable: publish HW_DEAD after worker is done") to prevent a race between GC and hw offload handler. Fixes: 2c8897953f3b ("netfilter: flowtable: Add pending bit for offload work") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 57605f2a27fdaba615637fbd9bc0461ce7dbe487 Author: Florian Westphal Date: Tue Jan 14 00:50:36 2025 +0100 netfilter: conntrack: rework offload nf_conn timeout extension logic [ Upstream commit 03428ca5cee9f0792edc996c06ce4514816af1fb ] Offload nf_conn entries may not see traffic for a very long time. To prevent incorrect 'ct is stale' checks during nf_conntrack table lookup, the gc worker extends the timeout nf_conn entries marked for offload to a large value. The existing logic suffers from a few problems. Garbage collection runs without locks, its unlikely but possible that @ct is removed right after the 'offload' bit test. In that case, the timeout of a new/reallocated nf_conn entry will be increased. Prevent this by obtaining a reference count on the ct object and re-check of the confirmed and offload bits. If those are not set, the ct is being removed, skip the timeout extension in this case. Parallel teardown is also problematic: cpu1 cpu2 gc_worker calls flow_offload_teardown() tests OFFLOAD bit, set clear OFFLOAD bit ct->timeout is repaired (e.g. set to timeout[UDP_CT_REPLIED]) nf_ct_offload_timeout() called expire value is fetched -> NF_CT_DAY timeout for flow that isn't offloaded (and might not see any further packets). Use cmpxchg: if ct->timeout was repaired after the 2nd 'offload bit' test passed, then ct->timeout will only be updated of ct->timeout was not altered in between. As we already have a gc worker for flowtable entries, ct->timeout repair can be handled from the flowtable gc worker. This avoids having flowtable specific logic in the conntrack core and avoids checking entries that were never offloaded. This allows to remove the nf_ct_offload_timeout helper. Its safe to use in the add case, but not on teardown. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 7c549fb7eecd ("netfilter: flowtable: generalize pending status bit") Signed-off-by: Sasha Levin commit b218da56f9e4795becfc4276fff5be3f98c5f12e Author: Florian Westphal Date: Tue Jan 14 00:50:35 2025 +0100 netfilter: conntrack: remove skb argument from nf_ct_refresh [ Upstream commit 31768596b15aa8c9c55f078acad29d0238c8269b ] Its not used (and could be NULL), so remove it. This allows to use nf_ct_refresh in places where we don't have an skb without having to double-check that skb == NULL would be safe. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 7c549fb7eecd ("netfilter: flowtable: generalize pending status bit") Signed-off-by: Sasha Levin commit ea777dc90ab37e64fa4b92f6fcf3b5edcef5e058 Author: Fernando Fernandez Mancera Date: Tue Sep 22 21:18:52 2026 +0200 netfilter: bpf: reject invalid NAT manipulation types [ Upstream commit 16d464013ec2267b00a83f4bfbb97b3ecc63bfa7 ] As bpf_ct_set_nat_info() is not validating the NAT manipulation type a wrong value can be passed directly to nf_nat_setup_info(). This triggers the WARN_ON() at nf_nat_setup_info() and if panic_on_warn isn't set, then IPS_SRC_NAT_DONE is set without adding nat_bysource and conntrack cleanup tries to unlink an uninitialized hlist node. Fix this by checking that NAT manipulation type is correct before calling nf_nat_setup_info(). In addition, if the WARN_ON is hit, return NF_DROP instead of continuing with the processing to avoid similar situations in the future. Reported-by: VEGA Fixes: 0fabd2aa199f ("net: netfilter: add bpf_ct_set_nat_info kfunc helper") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f4cd1db7d421e82945713a36084bb0c35b75b27e Author: Julian Anastasov Date: Sat Sep 19 21:07:33 2026 +0300 ipvs: filter some flags received in the backup server [ Upstream commit f96e91748f6304668fe647e686d199d7207d36f1 ] While the IPVS SYNC protocol is not secure by design we can still protect the backup server from messages that can wreak havoc. This commit addresses problems from received connection flags or their combinations. We now drop messages as follows: 1. the NO_CPORT+TEMPLATE combination allows lookups for normal connections to hit template which can break in many ways. While the master does not sync connections with NO_CPORT flag, i.e. before they are established, we still accept NO_CPORT without TEMPLATE. 2. ONE_PACKET: it is not sent by master, so we do not expect it in backup. Before now it was ignored by IP_VS_CONN_F_BACKUP_MASK for protocol v1 while protocol v0 created connections that are not hashed and dropped immediately. Better to apply the IP_VS_CONN_F_BACKUP_MASK also to the flags from v0 messages for consistency with v1. Fixes: 87375ab47cd0 ("[IPVS]: ip_vs_ftp breaks connections using persistence") Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fccc50f08c7eb686de3fc7ab77e0c8e4c34a544e Author: Julian Anastasov Date: Sat Sep 19 21:07:32 2026 +0300 ipvs: do not create invisible templates [ Upstream commit 616cf5c06934364ab1002b420ebe975850b4b208 ] The IP_VS_CONN_F_ONE_PACKET flag was implemented for normal connections. When conn template inherits this flag from dest->conn_flags it will not be hashed. As result, we will create new template for every new normal connection. Fix it to allow one template to be used by many normal connections. Fixes: 26ec037f9841 ("IPVS: one-packet scheduling") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260916231652.127456-1-pablo%40netfilter.org Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4e081b492d4d0acc173d2584e1be1a75c9c7f8c2 Author: Julian Anastasov Date: Thu Sep 10 13:08:31 2026 +0300 ipvs: fix missing counter decrement in lblc [ Upstream commit bdac17779f46817f60103baf09f0370546c3f023 ] LBLC may delete cache entries for destinations that are removed or overloaded and replace them with available ones. But ip_vs_lblc_new() forgets to decrement the tbl->entries counter after calling ip_vs_lblc_del(). This can lead to increased shrinking of the cache with every new garbage collection. Fixes: 2f3d771a35fe ("ipvs: do not use dest after ip_vs_dest_put in LBLC") Link: https://sashiko.dev/#/patchset/0bdd5abe9968ded7ca2b9cb6844ba83d94cc8d53.1787318053.git.zhilinz%40nebusec.ai Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c92ff2a266d14353977e85ad37edffd646cf4be0 Author: Jeff Jo Date: Thu Sep 24 15:44:58 2026 -0700 tcp: refresh TS.Recent for accepted old ACKs [ Upstream commit 1b92780ae4fc3be64f05d97ed8833c445e73b0cf ] A TCP packet can carry new data while acknowledging traffic in the opposite direction. With overlapping traffic in both directions, a delayed packet's acknowledgment can be older than one Linux has already accepted, even when that packet fills a gap in the received data. Linux accepts the data, but tcp_ack() takes the old_ack path and skips updating TS.Recent, the timestamp saved for outgoing acknowledgments. The reply therefore echoes an older timestamp. If the sender uses this echo to measure round-trip time after a long idle period, its estimate includes the idle time and can reduce its sending rate. Update TS.Recent in old_ack using tcp_replace_ts_recent(), before SACK processing can trigger a transmission. This reuses the existing timestamp and sequence checks, including PAWS protection against old duplicate packets. ACK validation already rejects old ACKs in SYN_RECV before this path, so no additional state check is needed. Echoing the timestamp of the packet that fills the receive gap follows RFC 7323 section 4.3. In a socket reproduction with 300 seconds idle, controlled reordering and retransmission to exercise timestamp-based RTT sampling, the sender's smoothed round-trip time was 37.5 seconds without the fix and 15.5 ms with it. Fixes: 12fb3dd9dc3c ("tcp: call tcp_replace_ts_recent() from tcp_ack()") Assisted-by: LLM sparse Signed-off-by: Jeff Jo Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 42001839e425b2564b7297be579073a13a8fddf6 Author: Sandeep Haemoon Date: Thu Sep 24 23:51:37 2026 +0300 net: ethernet: mtk_eth_soc: allocate dummy netdev sooner [ Upstream commit 6f0c2c4f5e7143eba75153ecc8af3a03f7b6a98b ] The RX rings and the shared NAPI are carried by an internal "dummy" netdev (eth->dummy_dev). mtk_probe() creates that dummy device, and adds the shared tx/rx NAPI to it, only after the MAC netdevs have been registered. That order has been there since the MT7623 support was added and leaves a window in which the netdevs are visible to the network core before the shared NAPI and the dummy device exist. If anything brings the first netdev up during that window (e.g. netifd opening the WAN link the instant the interface is registered), the first-open path runs without them. On NETSYS v2 and later SoCs mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev == NULL: WARNING: CPU: ... Missing net_device from driver in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs (MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open instead calls napi_enable() on a napi_struct that netif_napi_add() has not initialised yet and dereferences a NULL napi->dev. Allocate the dummy netdev and add the shared tx/rx NAPI to it before the register_netdev() loop. Both the dummy-allocation failure and a register_netdev() failure now unwind through mtk_unreg_dev(), which unregisters the net_device notifiers and the netdevs registered so far, stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the dummy carrier is freed. A netdev that opened during the window can also have queued the frame-engine reset worker (via the tx watchdog or phylink), so the probe error path now cancels eth->pending_work before freeing the shared state, as mtk_cleanup() already does on remove. Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet") Signed-off-by: Sandeep Haemoon Reviewed-by: Simon Horman Link: https://patch.msgid.link/patch-e52c13380b0768fec63af04c80e4b487@loljews.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6ec35c8267c84c2094cb485db20c06384fc2bcc Author: Jamal Hadi Salim Date: Mon Sep 28 08:46:16 2026 -0400 net: cap skb->queue_mapping when the tx queue is picked [ Upstream commit ea4d4b5dddb5121e64f56fd8e0720bd8b447b63d ] skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit. A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *. We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net-next) patch once this hits net-next to rename the skb->nf_skip_egress bit/flag to skb->skip_egress Arm the flag only from the egress classifier that can use it: raise skip_txqueue from tcf_skbedit_act() only when it runs inside sch_handle_egress(), thanks to skb->nf_skip_egress. An egress qdisc classifier runs in q->enqueue(), after the tx queue has been picked, so a mapping it sets cannot affect the current packet; arming the flag there only pollutes it for a later xmit. Then own the flag for the xmit frame the egress hook runs in: save the incoming value and clear it just before sch_handle_egress(), and restore it after the hook - on the consumed (drop) path, or, in the same call that reads it, on the surviving path. The save and the restores stay inside the egress_needed_key static branch, so a packet pays for them only when egress hooks are active (2f1e85b1aee4). Store the value netdev_cap_txqueue() selected back into skb->queue_mapping in netdev_tx_queue_mapping(), as netdev_core_pick_tx() already does, so the skip_txqueue path never hands a later reader on the xmit path a mapping the device cannot serve. A store made still later in the same frame, by a tc BPF program attached to a transmit qdisc, is outside this path and is not re-capped; a separate followup will resolve that path. netdev_xmit_skip_txqueue() returns the previous flag value so the save-and-clear is one call, and a no-op stub is provided when CONFIG_NET_EGRESS is disabled. skb->nf_skip_egress is compiled under CONFIG_NET_EGRESS rather than CONFIG_NETFILTER_SKIP_EGRESS, so skb_at_tc_egress() is valid whenever the egress path is built. A local user in a network namespace can redirect a packet from a device with more TX queues to one with fewer after setting a mapping valid only on the larger device. That reaches these reads and, under KASAN, faults with "slab-out-of-bounds in taprio_enqueue". Conditions to recreate the bug: the report's own trigger is a local user with CAP_NET_ADMIN in a network namespace, so no eBPF program is needed. With CONFIG_NET_SCH_TAPRIO=y, CONFIG_NET_ACT_SKBEDIT=y, CONFIG_NET_ACT_MIRRED=y, CONFIG_NET_CLS_MATCHALL=y, CONFIG_NET_SCH_PRIO=y and KASAN enabled, create qa (3 queues), qb (2 queues) and qc (1 queue) as dummy devices; put a taprio root on qb (num_tc 1, queues 2@0) and clsact on all three; then add an egress matchall filter on every device. On qa: "action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb". On qb: "action mirred egress mirror dev qc". On qc: "action skbedit queue_mapping 0 pipe". Send one packet out qa. qc's skbedit sets the flag while qb's outer xmit is in flight; without the fix qb consumes it and reads its two-entry taprio child array with the forwarded packet's stale mapping. A qc whose skbedit is instead installed in a transmit-qdisc classifier (a matchall filter on the qc root qdisc) reaches the same code path the same way without the fix. Testing: on a KASAN build with panic_on_warn=1 the unfixed kernel panics with "BUG: KASAN: slab-out-of-bounds in taprio_enqueue", a read 0 bytes past a 16-byte taprio_init() allocation, for the clsact-setter and the transmit-qdisc-classifier reproducers and for a clsact skbedit-then-tc-BPF store; the fixed kernel runs all three with no report, and the BPF store variant additionally shows the expected "selects TX queue" clamp notice from the write-back. Fixes: 2f1e85b1aee4 ("net: sched: use queue_mapping to pick tx queue") Reported-by: Zero Day Initiative Link: https://lore.kernel.org/netdev/CANn89iLwYx8nCVf0pCEk_MmEiyC6kQaMwCQT9WkQVeeNzNQHqQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/179008581937.2160803.7117814290574262942@kernel.org/ Link: https://lore.kernel.org/netdev/179033713973.2160803.4914570693994398206@kernel.org/ Link: https://lore.kernel.org/netdev/20260925180407.63647514@kernel.org/ Link: https://lore.kernel.org/netdev/CANn89i+k-mZKDQVtvws_MEXeuMTAdaCcOXFZE-RfhcGTu90sjA@mail.gmail.com/ Suggested-by: Eric Dumazet Suggested-by: Jakub Kicinski Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/QDISC-9R8V.v4.20260928081529@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d867b91598b6ed2f75998c34f4e2869631da31e Author: Nicolai Buchwitz Date: Mon Sep 28 12:56:41 2026 +0200 net: bcmgenet: fix NULL dereference in set_coalesce before first open [ Upstream commit 19419faf58dfe5bcc8a9e60e622976c5f8e3ddc1 ] The Rx ring priv and index are only set in bcmgenet_init_rx_ring(), which runs at open. Setting the Rx coalescing parameters on an interface that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences a NULL ring->priv. The oops happens with RTNL held, so networking stays stuck until a reboot: Unable to handle kernel paging request at virtual address 0000000000002788 pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 lr : bcmgenet_set_coalesce+0xe8/0x180 Call trace: bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P) __ethnl_set_coalesce.isra.0+0x490/0x570 ethnl_set_coalesce+0x48/0xc0 ethnl_default_set_doit+0xf4/0x230 genl_family_rcv_msg_doit+0xe8/0x160 genl_rcv_msg+0x220/0x2a0 netlink_rcv_skb+0x68/0x140 genl_rcv+0x40/0x60 netlink_unicast+0x338/0x3c0 netlink_sendmsg+0x19c/0x3f8 __sock_sendmsg+0x64/0xc0 __sys_sendto+0x124/0x198 __arm64_sys_sendto+0x30/0x48 Set priv and index at probe. Writing the registers while the interface is down is harmless because open resets the MAC and bcmgenet_init_rx_coalesce() reapplies the stored values. It was observed on a Raspberry Pi CM4, but should apply to all other genet devices. Fixes: 9f4ca05827a2 ("net: bcmgenet: Add support for adaptive RX coalescing") Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260928105642.856210-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e88a3008b536c29bee84cbdb24fed2f8b97f0f42 Author: Niklas Cassel Date: Fri Sep 18 16:06:42 2026 +0200 virtio_blk: set the zone write granularity [ Upstream commit 684b413b5483f57c890c171b9400076a0143b918 ] virtblk_read_zoned_limits() reads the write granularity that the device reports in virtio_blk_zoned_characteristics and assigns it to the physical block size and to io_min, but never to the limit that is named after it. queue_limits.zone_write_granularity is left at zero, so blk_validate_zoned_limits() raises it to the logical block size: if (lim->zone_write_granularity < lim->logical_block_size) lim->zone_write_granularity = lim->logical_block_size; A device that reports a granularity coarser than its logical block size, which is what the field exists to express, therefore has it silently reduced. A 512e host managed disk passed through to a guest reports a logical block size of 512 and a write granularity of 4096, and the guest ends up with a zone write granularity of 512. bio_split_alignment() returns lim->zone_write_granularity if it is non-zero and bio_split_io_at() may split a bio with as per bio_split_alignment(). This can real to the write getting rejected by the host drive, as the write is not aligned to the physical block size. zonefs also takes its block size from bdev_zone_write_granularity(), so it would incorrectly use 512 on a disk that requires 4096. sd_zbc_read_zones() sets the limit from the physical block size for the same reason. NVMe ZNS and null_blk leave it unset, but the fallback gives the right answer for them, as their write granularity is the logical block size. virtio carries a separate value that may exceed it. Set the zone write granularity from the value that the device reports. Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices") Signed-off-by: Niklas Cassel Reviewed-by: Stefan Hajnoczi Link: https://patch.msgid.link/20260918140641.2031075-2-cassel@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 38ace036d797ec3dabbbb4066b852f3ce981e990 Author: Jamal Hadi Salim Date: Sat Sep 26 14:03:28 2026 -0400 net/sched: sch_codel: match the no-drop threshold to the packet size [ Upstream commit 54518e0e827f4ca9229ae657022c60bf60f5c1bf ] commit 6439461f1618 ("net/sched: sch_codel: clamp default mtu to avoid disabling CoDel") clamped q->params.mtu to [256, 1 << 20]. The value is the CoDel no-drop threshold (codel_impl.h "*backlog <= params->mtu"), so on a link whose maximum transmitted packet size is below 256 the floor extends CoDel's minimum-backlog exemption beyond one packet and delays drop or mark eligibility by several small packets. Keep the upper bound that guards the original overflow (psched_mtu() wrapping to ~2 GiB on a huge-MTU device) but drop the 256 floor, so the threshold tracks the real device packet size. Conditions to recreate the bug: attach a codel qdisc on a link whose MTU plus hard_header_len is below 256 (e.g. a CAN interface). At that MTU the no-drop threshold must equal the device MTU plus its hard-header length; before this patch it was forced to 256. Requires CAP_NET_ADMIN in a user namespace. Fixes: 6439461f1618 ("net/sched: sch_codel: clamp default mtu to avoid disabling CoDel") Reported-by: Sashiko (nipa) Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260819143136.57350-1-jhs@mojatatu.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-34MS.v1.20260925165535@mojatatu.com.2 Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9eeff058e3667bef436587fb965f723754f720d5 Author: Jamal Hadi Salim Date: Sat Sep 26 14:03:27 2026 -0400 net/sched: fq_codel: match the no-drop threshold to the packet size [ Upstream commit d031465acc362866f27e4f8f79cfecf1037fe2e5 ] commit d9ebd8f9aa8b ("net/sched: fq_codel: clamp default quantum and mtu") clamped both q->quantum and q->cparams.mtu to [256, FQ_CODEL_QUANTUM_MAX]. The two fields mean different things: quantum is a DRR credit that wants the 256 floor, but cparams.mtu is the CoDel no-drop threshold (codel_impl.h "*backlog <= params->mtu"). On a link whose maximum transmitted packet size is below 256, the floor extends CoDel's minimum-backlog exemption beyond one packet and delays drop or mark eligibility by several small packets. Split the clamp. quantum keeps [256, FQ_CODEL_QUANTUM_MAX]; cparams.mtu tracks psched_mtu() (the device MTU plus its hard-header length) with only the upper bound that guards the original overflow (psched_mtu() wrapping to ~2 GiB on a huge-MTU device). Conditions to recreate the bug: attach an fq_codel qdisc on a link whose MTU plus hard_header_len is below 256 (e.g. a CAN interface). At that MTU the no-drop threshold must equal the device MTU plus its hard-header length; before this patch it was forced to 256. Basic Testing done: with dev->mtu=100 and hard_header_len=14, a return probe on fq_codel_init() observed cparams.mtu change from 256 to 114 Fixes: d9ebd8f9aa8b ("net/sched: fq_codel: clamp default quantum and mtu") Reported-by: Sashiko (nipa) Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260819143136.57350-1-jhs@mojatatu.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-34MS.v1.20260925165535@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 492e04f9a00f3cc88a1f6899417b10f3019a624e Author: Eric Dumazet Date: Fri Sep 25 13:52:43 2026 +0000 net: restrict SO_RESERVE_MEM to TCP sockets and cap max value [ Upstream commit 37e02c42a00be692c06343e11779aadc45f45971 ] Commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") only checked sk_has_account(sk), which is true for both TCP and UDP sockets. However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk->sk_forward_alloc is protected by sk->sk_receive_queue.lock, whereas sock_reserve_memory() and sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without accounting for sk_unused_reserved_mem(sk). Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed. In addition, reject val > SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages << PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk->sk_forward_alloc and sk->sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk->sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be passed back to setsockopt(SO_RESERVE_MEM). Fixes: 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") Reported-by: Cai Xinchen Closes: https://lore.kernel.org/netdev/5a88421d-10ef-4fca-9acb-85a27a3c1173@huawei.com/ Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20260925135244.3715196-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d8575c40ffdb2ae357d37e32b0dcd7540ccf0a2 Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:15 2025 +0000 net-memcg: Introduce mem_cgroup_sk_enabled(). [ Upstream commit 43049b0db03823c2cd003ca7d3dddcd3924da8dc ] The socket memcg feature is enabled by a static key and only works for non-root cgroup. We check both conditions in many places. Let's factorise it as a helper function. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Acked-by: Roman Gushchin Acked-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-8-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 37e02c42a00b ("net: restrict SO_RESERVE_MEM to TCP sockets and cap max value") Signed-off-by: Sasha Levin commit 184f87f256ecd11af9f77ad51063ae0dab6239ea Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:14 2025 +0000 net-memcg: Introduce mem_cgroup_from_sk(). [ Upstream commit f7161b234f2ec7f18999009c4becc04eeb6b12a7 ] We will store a flag in the lowest bit of sk->sk_memcg. Then, directly dereferencing sk->sk_memcg will be illegal, and we do not want to allow touching the raw sk->sk_memcg in many places. Let's introduce mem_cgroup_from_sk(). Other places accessing the raw sk->sk_memcg will be converted later. Note that we cannot define the helper as an inline function in memcontrol.h as we cannot access any fields of struct sock there due to circular dependency, so it is placed in sock.h. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Acked-by: Roman Gushchin Acked-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-7-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 37e02c42a00b ("net: restrict SO_RESERVE_MEM to TCP sockets and cap max value") Signed-off-by: Sasha Levin commit a8c5f949556dfbb4303d6ce7723ecdf5b09ae209 Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:13 2025 +0000 net: Clean up __sk_mem_raise_allocated(). [ Upstream commit bd4aa2337374dd04b8627efd26227ebd49f69285 ] In __sk_mem_raise_allocated(), charged is initialised as true due to the weird condition removed in the previous patch. It makes the variable unreliable by itself, so we have to check another variable, memcg, in advance. Also, we will factorise the common check below for memcg later. if (mem_cgroup_sockets_enabled && sk->sk_memcg) As a prep, let's initialise charged as false and memcg as NULL. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-6-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 37e02c42a00b ("net: restrict SO_RESERVE_MEM to TCP sockets and cap max value") Signed-off-by: Sasha Levin commit cce9dbd1ea56891bdb7b28ef58f879d4f11f4089 Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:09 2025 +0000 mptcp: Fix up subflow's memcg when CONFIG_SOCK_CGROUP_DATA=n. [ Upstream commit 68889dfd547bd8eabc5a98b58475d7b901cf5129 ] When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets sk->sk_memcg based on the current task. MPTCP subflow socket creation is triggered from userspace or an in-kernel worker. In the latter case, sk->sk_memcg is not what we want. So, we fix it up from the parent socket's sk->sk_memcg in mptcp_attach_cgroup(). Although the code is placed under #ifdef CONFIG_MEMCG, it is buried under #ifdef CONFIG_SOCK_CGROUP_DATA. The two configs are orthogonal. If CONFIG_MEMCG is enabled without CONFIG_SOCK_CGROUP_DATA, the subflow's memory usage is not charged correctly. Let's move the code out of the wrong ifdef guard. Note that sk->sk_memcg is freed in sk_prot_free() and the parent sk holds the refcnt of memcg->css here, so we don't need to use css_tryget(). Fixes: 3764b0c5651e3 ("mptcp: attach subflow socket to parent cgroup") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Acked-by: Matthieu Baerts (NGI0) Acked-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 37e02c42a00b ("net: restrict SO_RESERVE_MEM to TCP sockets and cap max value") Signed-off-by: Sasha Levin commit 8efa34c2f0562b0c3b154a69cd0b36d30e2b19f8 Author: Kuniyuki Iwashima Date: Thu Jul 17 19:46:43 2025 +0000 memcg: convert memcg->socket_pressure to u64 [ Upstream commit 378bdb97405a00bf03d8d993435c83add1688e36 ] memcg->socket_pressure is initialised with jiffies when the memcg is created. Once vmpressure detects that the cgroup is under memory pressure, the field is updated with jiffies + HZ to signal the fact to the socket layer and suppress memory allocation for one second. Otherwise, the field is not updated. mem_cgroup_under_socket_pressure() uses time_before() to check if jiffies is less than memcg->socket_pressure, and this has a bug on 32-bit kernel. if (time_before(jiffies, memcg->socket_pressure)) return true; As time_before() casts the final result to long, the acceptable delta between two timestamps is 2 ^ (BITS_PER_LONG - 1). On 32-bit kernel with CONFIG_HZ=1000, this is about 24 days. >>> (2 ** 31) / 1000 / 60 / 60 / 24 24.855134814814818 Once 24 days have passed since the last update of socket_pressure, mem_cgroup_under_socket_pressure() starts to lie until the next 24 days pass. We don't need to worry about this on 64-bit machines unless they serve for 300 million years. >>> (2 ** 63) / 1000 / 60 / 60 / 24 / 365 292471208.6775361 Let's convert memcg->socket_pressure to u64. Performance teting: I don't have a real 32-bit machine so this is a result on QEMU, but with/without the u64 jiffie patch, the time spent in mem_cgroup_under_socket_pressure() was 1~5us and I didn't see any measurable delta. no patch applied: iperf3 273 [000] 137.296248: probe:mem_cgroup_under_socket_pressure: (c13660d0) c13660d1 mem_cgroup_under_socket_pressure+0x1 ([kernel.kallsyms]) iperf3 273 [000] 137.296249: probe:mem_cgroup_under_socket_pressure__return: (c13660d0 <- c1d8fd7f) iperf3 273 [000] 137.296251: probe:mem_cgroup_under_socket_pressure: (c13660d0) c13660d1 mem_cgroup_under_socket_pressure+0x1 ([kernel.kallsyms]) iperf3 273 [000] 137.296253: probe:mem_cgroup_under_socket_pressure__return: (c13660d0 <- c1d8fd7f) u64 jiffies patch applied: iperf3 308 [001] 330.669370: probe:mem_cgroup_under_socket_pressure: (c12ddba0) c12ddba1 mem_cgroup_under_socket_pressure+0x1 ([kernel.kallsyms]) iperf3 308 [001] 330.669371: probe:mem_cgroup_under_socket_pressure__return: (c12ddba0 <- c1ce98bf) iperf3 308 [001] 330.669382: probe:mem_cgroup_under_socket_pressure: (c12ddba0) c12ddba1 mem_cgroup_under_socket_pressure+0x1 ([kernel.kallsyms]) iperf3 308 [001] 330.669384: probe:mem_cgroup_under_socket_pressure__return: (c12ddba0 <- c1ce98bf) So the u64 approach is good enough. Link: https://lkml.kernel.org/r/20250717194645.1096500-1-kuniyu@google.com Fixes: 8e8ae645249b ("mm: memcontrol: hook up vmpressure to socket pressure") Signed-off-by: Kuniyuki Iwashima Reported-by: Neal Cardwell Suggested-by: Andrew Morton Acked-by: Shakeel Butt Acked-by: Johannes Weiner Cc: David S. Miller Cc: Eric Dumazet Cc: Johannes Weiner Cc: Vladimir Davydov Signed-off-by: Andrew Morton Stable-dep-of: 37e02c42a00b ("net: restrict SO_RESERVE_MEM to TCP sockets and cap max value") Signed-off-by: Sasha Levin commit 5c8ce13c792e28d56f9ec3cd6728d8225bc0e3a2 Author: Jérémy Jean Date: Thu Sep 24 20:21:05 2026 +0000 tipc: prevent GCM nonce reuse on peer key changes [ Upstream commit 512ccd3d0e91e791fb37442aa0a2599aca19783d ] TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce. Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed. The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Signed-off-by: Jérémy Jean Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260924202105.3722778-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75f26d35ebc2dd274e32b809da368764af21752b Author: Baha Mesleh Date: Tue Sep 22 15:51:49 2026 +0530 octeontx2-af: mcs: Fix SC resource cleanup loop [ Upstream commit cdef07f3002f708a345392ee28d0d9bfac8383a1 ] The SC resource cleanup and statistics loops were incorrectly iterating over secy.max instead of sc.max, so the highest SC id could be left allocated across teardown or FLR. Use sc.max as the loop bound. Fixes: cfc14181d497 ("octeontx2-af: cn10k: mcs: Manage the MCS block hardware resources") Signed-off-by: Baha Mesleh Signed-off-by: Subrat Pandey Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260922102149.2078168-3-subratp@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16ca0e79f31ea810346a79dda545ba344ede1d47 Author: Anirudh Virdi Date: Thu Sep 24 12:12:44 2026 +0530 net/mlx5: Fix slab-out-of-bounds when handling team device events [ Upstream commit 04c824940d52871c49866a4ac67b504146f7cf35 ] The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port is smaller than bond slave. Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices. For mlx5_handle_changeinfodata_event(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway. Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors) Fixes: 54493a08e21f ("net/mlx5: Lag, record inactive state of bond device") Suggested-by: Mark Bloch Signed-off-by: Anirudh Virdi Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20260924064244.94045-1-avirdi@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8330e9f0214c0f0b73c57b3f3f619b64c8035029 Author: Rongwei Liu Date: Thu Dec 19 19:58:31 2024 +0200 net/mlx5: LAG, Refactor lag logic [ Upstream commit ddbb5ddc43ad000a984149db5af1133433938404 ] Wrap the lag pf access into two new macros: 1. ldev_for_each() 2. ldev_for_each_reverse() The maximum number of lag ports and the index to `natvie_port_num` mapping will be handled by the two new macros. Users shouldn't use the for loop anymore. Signed-off-by: Rongwei Liu Reviewed-by: Saeed Mahameed Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20241219175841.1094544-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 04c824940d52 ("net/mlx5: Fix slab-out-of-bounds when handling team device events") Signed-off-by: Sasha Levin commit 257ac9a83c97842d23b1f8bdbbd94d6d24ac9ad9 Author: Florian Fainelli Date: Tue Sep 22 16:24:35 2026 -0700 net: systemport: Fix RUNT MIB counter register offset calculation [ Upstream commit 242935adfeb096f09b29fb2cfcf12f9eb2911fc6 ] In UniMAC hardware, there is a 0xC byte gap between the RX MIB counters and the TX MIB counters, and a second 0xC byte gap between the TX MIB counters and the RX RUNT MIB counters. In bcm_sysport_update_mib_counters(), 'offset' was only set to UMAC_MIB_STAT_OFFSET (0xC) for all non-RX counters, omitting the second 0xC gap for BCM_SYSPORT_STAT_RUNT counters. As a result, all 4 RUNT MIB counters were read from unmapped gap register space. Fix this by setting offset to 2 * UMAC_MIB_STAT_OFFSET (0x18) when reading BCM_SYSPORT_STAT_RUNT counters. Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260922232440.598918-6-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 29d1d35ad5ad379a904263ea1cd4ba1d71cd965f Author: Florian Fainelli Date: Tue Sep 22 16:24:31 2026 -0700 net: systemport: Fix buffer overflow in bcm_sysport_get_stats() [ Upstream commit eb7b84af0ec5c71b4920e999611b466b3784496c ] When running on SYSTEMPORT Lite, certain statistics are unsupported and skipped during bcm_sysport_get_stats(). The variable 'j' tracks the compacted index into the destination data buffer, whereas 'i' iterates over all elements in bcm_sysport_gstrings_stats. Because the buffer allocated by ethtool is sized only according to bcm_sysport_get_sset_count(), storing values at data[i] instead of data[j] writes past the allocated array bounds, leading to memory corruption. Fix this by writing to data[j] instead of data[i]. Fixes: 10377ba7673d ("net: systemport: Support 64bit statistics") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260922232440.598918-2-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 143bde97c4101ae68eb656c87e620c45b07a3090 Author: Nguyen Ngoc Thang Date: Sun Sep 27 22:18:02 2026 +0700 Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister [ Upstream commit b1f24c1ab52345e810c42a1a81286cb5a7c92252 ] hci_unregister_dev() disables cmd_work and cmd_timer, then calls hci_cmd_sync_clear(), whose cancel_work_sync() waits for hci_cmd_sync_work() to return. That worker dequeues and runs every entry on cmd_sync_work_list. With cmd_work disabled nothing reaches the controller, so each queued HCI command waits the full HCI_CMD_TIMEOUT (2s). The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhci_release() for backlog * 2s: INFO: task syz-executor:5749 blocked for more than 143 seconds. cancel_work_sync hci_cmd_sync_clear hci_unregister_dev vhci_release In a local reproduction the backlog held more than 5000 entries, which comes to hours of hang. Stop the worker from taking new entries once HCI_UNREGISTER is set, and wake any request still waiting with -ENODEV before cancelling the work. The entries left over are destroyed with -ECANCELED by the existing sweep in hci_cmd_sync_clear(). They stay on the list until the work has stopped, so hci_cmd_sync_dequeue() and friends still see them. A callback already running may still issue another command, which delays unregister by at most one timeout per remaining command, not by the whole backlog. Fixes: 008ee9eb8a11 ("Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work") Reported-by: syzbot+217e3f1283cafe80586e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=217e3f1283cafe80586e Signed-off-by: Nguyen Ngoc Thang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1f9c2f5c31b12503566a946cb632202cc52b8c0c Author: Florian Westphal Date: Fri Sep 4 20:03:07 2026 +0200 netfilter: ipset: do not update comments from kernel-side adds [ Upstream commit a442c8a89fb9c531f9d6ab86120c31decd778d51 ] 'Fixes' commit stopped calling ip_set_init_comment() for hash types from kernel-side-adds (xtables .. -j SET). ip_set_init_comment() says: "The kadt functions don't use the comment extensions in any way." But bitmap set type calls the function from kadt cb too. While this appears to be safe (serialized via the set spinlock), it seems better to not call the init function either, least of all to keep behaviour consistent. ip_set_list calls ip_set_init_comment() only from uadt cb, it can be kept as-is. This was triggered by yet another LLM review, hinting that the existing rcu_dereference_protected() cannot be downgraded to only check if the nfnl mutex is held. Fixes: f30415929be8 ("netfilter: ipset: do not update comments from kernel-side hash adds") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b47c34e9e6aa2a6f662a3cae878049133d659bfd Author: Qishuai Liu Date: Wed Sep 23 13:20:48 2026 +0000 ipv6: fix prefix route expiry in modify_prefix_route() [ Upstream commit a7bfaba4823e3c165bb2004c74eff7c096672bc7 ] modify_prefix_route() is given the lifetime in clock_t relative to now, but fib6_set_expires() wants an absolute jiffies value. So when a permanent address is changed to a finite valid_lft, the prefix route ends up already expired and GC removes it. Steps to reproduce: ip link add dummy9 type dummy ip link set dummy9 up ip -6 addr add 2001:db8:9::1/64 dev dummy9 ip -6 addr change 2001:db8:9::1/64 dev dummy9 valid_lft 3600 preferred_lft 3600 ip -6 route show dev dummy9 # expires is negative Fixes: 8308f3ff1753 ("net/ipv6: Add support for specifying metric of connected routes") Signed-off-by: Qishuai Liu Reviewed-by: Hangbin Liu Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260923132048.3272878-1-lqs@lqs.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 315e4fe65cf02ef052de5e6298c3088e448b7517 Author: Jamal Hadi Salim Date: Thu Sep 24 04:32:49 2026 -0400 net/sched: cls_api: reclaim an empty proto on the error path [ Upstream commit 0bb8eab29b55045281a4963d4557f2776cdf8cfa ] Two racing tc filter add requests on the same chain/prio of an unlocked classifier both run change() on the shared proto and both can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up because the loser's handle is still in the idr, and the loser's error path drops only its own reference without a second reclamation attempt. The empty proto stays linked in the chain, holding the chain reference, a block reference and the classifier module reference until the chain or block is torn down. Reclaim the proto on the error path of any failed request that holds a proto reference. The reclamation is emptiness-gated: tcf_chain_tp_delete_empty() unlinks the proto only when delete_empty() admits it is empty, so a live shared proto is never unlinked. A proto the request created is reclaimed unconditionally - it is the only owner, so marking it for deletion is safe even without a delete_empty callback. Classifiers without one (the check marks the proto unconditionally) are rtnl-serialized, so the raced window this guard closes cannot arise for them. This is a follow-up to commit d4e359b3608a ("net/sched: cls_api: fix teardown of an adopted proto on insert-race loss"), which stopped the loser of the insert race from unlinking the winner's live proto but left the empty-proto residual in place. Conditions to recreate: - CONFIG_NET_CLS_FLOWER=y; veth pair - tc qdisc add dev veth0 ingress - two concurrent `tc filter add dev veth0 ingress protocol ip pref 1 flower skip_sw ... action drop` (both fail in fl_hw_replace_filter after publishing their handle in the idr); repeat in a loop - an empty flower tp stays linked after both requests fail; visible as a bare `filter protocol ip pref 1 flower chain 0` header in `tc filter show` with no filter entries - CAP_NET_ADMIN (namespace-local via unshare -Urn suffices) Fixes: 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution") Reported-by: Sashiko (nipa) Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260805134049.927864-1-victor@mojatatu.com Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-JCOT.v1.20260910090924@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit af6e4f931afc2d670d133aa2bedc8b6e3753c618 Author: Binbin Deng <18983559317@163.com> Date: Tue Sep 22 21:19:19 2026 +0800 net/mctp: publish the mctp_dev only after it is initialised [ Upstream commit aadf655e8ea9a8ffa24bb8d69f504572e8d18181 ] mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev is assigned, so a reader that picks the device up in that window dereferences a net_device pointer that is still NULL: KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace: ? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49) ? __pfx_mctp_dst_output (net/mctp/route.c:41) ? selinux_socket_sendmsg (security/selinux/hooks.c:5278) ____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790 (discriminator 1) net/socket.c:2684 (discriminator 1)) ? __pfx_____sys_sendmsg (net/socket.c:1131) ? __pfx_copy_msghdr_from_user (net/socket.c:2590) ? update_cfs_rq_load_avg (kernel/sched/fair.c:5478) ___sys_sendmsg (net/socket.c:2738) ? __pfx____sys_sendmsg (net/socket.c:2625) ? perf_event_task_tick (./include/linux/rcupdate.h:838) ? sched_tick (kernel/sched/core.c:5818) ? clockevents_program_event (kernel/time/clockevents.c:372) ? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100) __sys_sendmsg (net/socket.c:2770) ? __pfx___sys_sendmsg (net/socket.c:2751) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fix by publishing only once the object is fully initialised: __mctp_dev_get() runs under rcu_read_lock() only and hands this object to readers as soon as mctp_ptr is assigned, so they must never observe mdev->dev == NULL. Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Binbin Deng <18983559317@163.com> Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/729830b8.130.1a0c945579d.Coremail.18983559317@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 069031f569f1681f17e863f48c221a6091b47850 Author: Sai Teja Aluvala Date: Tue Sep 22 18:33:11 2026 +0530 Bluetooth: btintel: validate DDC record lengths [ Upstream commit c9c15d4d8956df8c564f7c210e4dc5b9b820d97a ] Parse DDC record lengths in unsigned storage so 0xFF does not wrap. Reject records smaller than the mandatory three-byte header, records exceeding U8_MAX, and records exceeding remaining firmware bytes before issuing Intel_Write_DDC. This issue was reported by Claude Mythos. Fixes: 145f2368c5fd ("Bluetooth: btintel: Add Device Configuration support") Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3532add173a8f840c6d4b30f1f90bb0d6025c4ec Author: Sang-Hoon Choi Date: Tue Sep 22 03:49:28 2026 +0900 Bluetooth: hci_core: free the HCI ID if naming fails [ Upstream commit d1ac915fb4184faad1b62148be50f317de7c24b5 ] hci_register_dev() allocates an ID before calling dev_set_name(). If naming fails, it returns without releasing that ID. The device has not been registered and hdev->id has not been assigned, so the normal unregister path cannot release it. Free the allocated ID before returning the naming error. Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings") Reported-by: Changyul Lee Assisted-by: LLM Signed-off-by: Sang-Hoon Choi Reported-by: Changyul Lee Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 32d5917a8754722eb870a11953a0b1777e01e70f Author: Cezary Rojewski Date: Fri Sep 18 13:17:45 2026 +0200 ASoC: codecs: rt274: Fix format setting for 44100 rate [ Upstream commit 6eda8938a790f65bd24fcfaae7b40ad4613fb7a2 ] As per specification, Sample Base Rate (bit 14) shall be set to 1 for 44.1 kHz. Fixes: c7e79b2b2d2d ("ASoC: rt274: add rt274 codec driver") Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260918111745.3589393-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2eed00c4db09431a76f2cb8c14a185369b150518 Author: Cezary Rojewski Date: Fri Sep 18 13:17:44 2026 +0200 ASoC: codecs: rt286: Revert delay value for jack setup [ Upstream commit d30fba93ebfc11e4604a7fcc73fdf28684191dde ] Fat fingered the change when reorganizing the jack-detect initialization. Equivalent changes for rt274 and rt298: Commit a43b4394bb35 ("ASoC: codecs: rt274: Always init jack_detect_work") Commit 1eb73102da28 ("ASoC: codecs: rt298: Reorganize jack detect handling") carry no update to the delay value. >From user perspective, no difference has been observed between 1250 and 50 values on Intel's SkyLake, KabyLake and AmberLake configurations. Fixes: 3082afe097cc ("ASoC: codecs: rt286: Reorganize jack detect handling") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260918111745.3589393-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd875e24e8f2b202e3636b3ef8e6060874eca0e5 Author: Felix Fietkau Date: Wed Sep 16 11:48:32 2026 +0200 wifi: mac80211: prevent AP VLAN tx from other interfaces [ Upstream commit 7f93ca31f7fd9b42e7d692f59514436d448ac908 ] Since the station lookup was factored out of ieee80211_build_hdr(), ieee80211_lookup_ra_sta() uses sta_info_get_bss() for all AP and AP VLAN frames, not only for control port frames. A unicast frame sent on one interface thus matches a station of a different VLAN of the same BSS and is transmitted to it. Only match stations of the interface the frame is sent on, except for control port frames, since those may be sent for VLAN stations directly on the BSS interface. Fixes: 97ffe75791b3 ("mac80211: factor out station lookup from ieee80211_build_hdr()") Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260916094833.164219-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4259dc40933e4477f038f0d1c137bb3e5a01632e Author: Tamizh Chelvam Raja Date: Thu Jun 4 21:54:03 2026 +0530 wifi: mac80211: Add 802.3 multicast encapsulation offload support [ Upstream commit 4cc0cc0b297c17c2b106d6892bd13d9c32fe66ce ] mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg Stable-dep-of: 7f93ca31f7fd ("wifi: mac80211: prevent AP VLAN tx from other interfaces") Signed-off-by: Sasha Levin commit 9a5833fc3831a6e9eb9d39af0c1fd46e3bb08006 Author: Tamizh Chelvam Raja Date: Thu Jun 4 21:54:02 2026 +0530 wifi: mac80211: Add multicast to unicast support for 802.3 path [ Upstream commit 2307b36ce34fd2166509ea2aeef0de5768ed03b7 ] mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: 7f93ca31f7fd ("wifi: mac80211: prevent AP VLAN tx from other interfaces") Signed-off-by: Sasha Levin commit 49b66110a08e4f926f6393e938f226de2750a08b Author: Zhao Li Date: Mon Sep 14 23:28:25 2026 +0800 wifi: cfg80211: preserve hidden-group beacon IE ownership [ Upstream commit cc45f313d85533d647ce619326302aad6f797c14 ] A hidden-group probe-response entry borrows its beacon IEs from the group's beacon entry. cfg80211_update_assoc_bss_entry() can pass such an entry to cfg80211_update_known_bss() when merging scan entries after a channel switch. Copying the borrowed beacon_ies into the associated entry gives the same allocation two owners. Releasing the group's beacon entry can then leave the associated entry pointing to freed IEs, which are freed again when that entry is released. Skip beacon IE replacement when the source entry belongs to a hidden group. Preserve probe-response processing, the subsequent metadata updates, and the existing rejection path for conflicting hidden beacon updates. Fixes: 0afd425b1b64 ("cfg80211: fix duplicated scan entries after channel switch") Reported-by: Yilin Zhang Closes: https://lore.kernel.org/linux-wireless/20260901080427.1983015-1-yilinzhang@moonshot.ai/ Assisted-by: Codex:gpt-6-astra Signed-off-by: Zhao Li Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 74dc7c52946e3d47c40edd0875adb7cc15937066 Author: Manush Prajwal Date: Sun Sep 6 16:44:09 2026 +0530 rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() [ Upstream commit ac41b05d15db3134e839148290d67415ee0bdb58 ] devm_clk_get(&pdev->dev, "rtcref")'s return value was passed straight into clk_get_rate() without checking it for an error first, unlike the "rtc" clock a few lines above which is correctly checked with IS_ERR(). clk_get_rate() only guards against a NULL clk, not an error pointer: if (!clk) return 0; ... rate = clk_core_get_rate_recalc(clk->core); so if devm_clk_get() ever returns an error pointer here (for example ERR_PTR(-EPROBE_DEFER), which is the normal, expected outcome if the clkcfg clock-provider this RTC depends on has not registered its clocks yet by the time this driver probes), clk_get_rate() dereferences that error pointer instead of returning 0, crashing instead of letting probe defer. Capture the clock in the existing 'clk' local and check it with IS_ERR() before calling clk_get_rate(), matching the handling already used for the "rtc" clock in this same function. Signed-off-by: Manush Prajwal Fixes: 0b31d703598d ("rtc: Add driver for Microchip PolarFire SoC") Reviewed-by: Conor Dooley Link: https://patch.msgid.link/6a9d4b02.7d74b517.206c4c.75f8@mx.google.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 12bcd20d76703ee2baf52224d287b7fea096b12f Author: Aamir Ahmed Date: Sat Sep 5 21:41:52 2026 +0100 rtc: ac100: Fix clock provider use-after-free on probe failure [ Upstream commit fcf0b58e976e83adf246b014518e49c662b96f5e ] ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device's managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip->rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip->clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100_rtc 0>. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does. The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the same device fail. The error path that returns -EINVAL when the ADDA 4M parent clock cannot be found leaks the RTC-32k clock in the same way. No provider has been registered at that point, so that one is a leak rather than a use-after-free. Register both with devm_clk_hw_register_fixed_rate() and devm_of_clk_add_hw_provider() so that they are released whenever the device goes away, on a failed probe as well as on unbind. Devres releases in reverse order of acquisition, so the provider is removed before chip->clk_data is freed, and the clkout children are now unregistered before their parent rather than after it. ac100_rtc_unregister_clks() and the remove callback then have nothing left to do and are removed. Fixes: d00a18a42c14 ("rtc: ac100: Add RTC driver for X-Powers AC100") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-rtc/20260905184936.155E11F00A3A@smtp.kernel.org/ Assisted-by: LLM Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB0001A489CC45A591ABBB9BDCC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 527b04c23ee29b73b03866ae04432a1ae8cd6277 Author: Uwe Kleine-König Date: Mon Oct 7 22:58:03 2024 +0200 rtc: Switch back to struct platform_driver::remove() [ Upstream commit e5eab1aeae765c30bd2ef50156dc9698c239ad31 ] After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/rtc to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20241007205803.444994-6-u.kleine-koenig@baylibre.com Signed-off-by: Alexandre Belloni Stable-dep-of: fcf0b58e976e ("rtc: ac100: Fix clock provider use-after-free on probe failure") Signed-off-by: Sasha Levin commit beda3c9730ad3087d01aa1d0415c40942042ec87 Author: Liu Dalin Date: Thu Aug 27 09:54:44 2026 +0800 rtc: dev: zero-initialize struct rtc_wkalrm to prevent information leak [ Upstream commit 0ee5c5d804d592a8328a425b9274487d393d3a05 ] The struct rtc_wkalrm has padding holes after the 'pending' member. When returned to userspace via the RTC_WKALRM_RD ioctl, uninitialized kernel stack data residing in these holes may be leaked. Zero-initialize the struct at declaration to eliminate this information leak risk. Fixes smatch warnings: - drivers/rtc/dev.c:392 rtc_dev_ioctl() warn: check that 'alarm' doesn't leak information (struct has a hole after 'pending') Fixes: 36e14f5fdfdf ("rtc: rename core files") Assisted-by: smatch:2.0 [static analysis] Signed-off-by: Liu Dalin Link: https://patch.msgid.link/B28B7DE18F3A9447+20260827015444.3314227-1-liudalin@kylinsec.com.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c18882768a0fe253c70986c5fe66d9241570fbc4 Author: Georgios Karantzas Date: Fri Sep 11 03:11:43 2026 +0300 wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE [ Upstream commit aeaca27c1db3106967ffbb2b517d98c835f6d500 ] __hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length. With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 * 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past tx_buf->buf before usb_submit_urb(). Peek the queue head and stop before copying any record that would cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion. The byte bound changes the loop's exit semantics: it can now exit before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make tx_buf->len a running total and advance tx_buf->offset per record instead; the stride round_up(nskb->len + 4, 4) is identical to the stock stride when the loop runs to completion. Tested on hardware with an MTU 2304 flood: the loop stops at record 15 (len = 32144, offset = 32144, within 32768), no oversized URB is submitted, and MTU 1500 pings pass 20/20. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Georgios Karantzas Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260911001143.4507-1-gck.kara@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 03ef61d05aa26022327f971b790f07e6bf6e35d6 Author: Pengpeng Hou Date: Fri Aug 14 15:58:37 2026 +0800 wifi: ath9k: reject short WMI command responses [ Upstream commit 93ce8ea70451e800601bc9444aa33043de15d67b ] ath9k_wmi_rsp_callback() removes the validated WMI header and copies the number of bytes expected by the waiting command into its response buffer. A device response shorter than that expectation can therefore be read beyond the skb payload. Record -EMSGSIZE for a short response, complete the waiter, and return the stored status from the command path. This also prevents callers from consuming stale response bytes as a successful reply. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Assisted-by: LLM Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260814075837.20005-1-pengpeng@iscas.ac.cn Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c3ac51701e925e8d50479ae2fddca51a09f636e8 Author: Nicolas Escande Date: Wed Aug 12 16:58:05 2026 +0200 wifi: ath11k: reset ar->num_stations on hardware start [ Upstream commit 7e0ad05ebc72fffba2bdf2400400902d94ed7272 ] When (multiple) hw restart occurs, we end up in a situation where we cannot accept new stations / mesh peers. This seems to be the 'num_stations' in 'struct ath11k' that did not get reset properly in this case. In ath11k_mac_op_start(), it was indeed the only accounting var that did not get reset so let's clear it too. This avoids problems like those: [1248828.088023] WARNING: CPU: 0 PID: 12281 at net/mac80211/util.c:1682 ieee80211_reconfig_stations+0x98/0xc0 [1248828.088115] Call trace: [1248828.088116] ieee80211_reconfig_stations+0x98/0xc0 (P) [1248828.088119] ieee80211_reconfig+0x774/0x1438 [1248828.088123] ieee80211_restart_work+0x10c/0x178 [1248828.088127] process_one_work+0x178/0x3c0 [1248828.088130] worker_thread+0x280/0x440 [1248828.088133] kthread+0xe0/0xf8 [1248828.088137] ret_from_fork+0x10/0x20 [1248828.088141] ---[ end trace 0000000000000000 ]--- [1248836.686604] ath11k_pci 0000:04:00.0: refusing to associate station: too many connected already (128) [1248836.686609] ath11k_pci 0000:04:00.0: Failed to add station: xx:xx:xx:xx:xx:xx for VDEV: 1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260812-num-station-v3-1-871d20e043f6@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 61214b86967a820f91fafc14fb4feb5c926db9ec Author: Sheetal Date: Mon Sep 21 08:57:02 2026 +0000 ASoC: tegra: Fix ASRC Stream6 input threshold control [ Upstream commit 75fc8a3ee5aee72f2fea3b6436170fae175f7f19 ] The Stream6 Input Threshold control points at stream index 4, which is already used by Stream5. The threshold get and put callbacks derive the lane ID from the register offset, so the duplicate index makes Stream6 operate on lane 4 and leaves lane 5 inaccessible from userspace. Use stream index 5 for Stream6. Fixes: a2df8c2d5b36 ("ASoC: tegra: Add Tegra186 based ASRC driver") Signed-off-by: Sheetal Reviewed-by: Thierry Reding Link: https://patch.msgid.link/20260921085704.1248920-2-sheetal@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 02886c18a340da59df57365f29009e1258bfe333 Author: Aamir Ahmed Date: Sat Sep 12 14:47:55 2026 +0100 wifi: wfx: validate MIB read length before copying to caller [ Upstream commit ce67ebe9d8629776ce38e6995ae72fb903c828db ] wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation. Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy. Fixes: f95a29d40782 ("staging: wfx: add HIF commands helpers") Assisted-by: LLM Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB000155034FC391A2A54B9803C8BD2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d60c67bda77003fbf22fe7e82a7c5765a0ee1c86 Author: HyeongJun An Date: Sun Sep 20 22:53:27 2026 +0900 ASoC: wm8903: Move the DRC QR threshold to the register that holds it [ Upstream commit e31ae4aeb049983fe3be0cf1e12c8074811a7685 ] The DRC_THRESH_QR field is bits 7 and 6 of DRC_1, but the control sits on DRC_0. Its shift and max are right for the field, only the register is wrong. Those bits of DRC_0 belong to DRC_STARTUP_GAIN, which "DRC Startup Volume" claims as bits 10 to 6. So the two controls share bits 7 and 6. Writing either one moves the other, and the quick release threshold is never reached at all. The six fields of DRC_1 tile it exactly, so there is nowhere else the threshold could live. Point the control at DRC_1. Found by a sweep for two controls claiming the same bits of one register. No board with this codec was to hand, the register map is the driver's own wm8903.h. Fixes: f1c0a02f32f8 ("ALSA: ASoC: Add WM8903 CODEC driver") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260920135327.3628704-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a00b484417e75ae3274ee3ea2e2c715a76a4525 Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:25 2026 -0700 of/overlay: don't create "//" paths for fragments targeting the root [ Upstream commit 21c89ff1fc86ffa517f3a9ca1ba5c48e9e37c1ba ] dup_and_fixup_symbol_prop() rewrites a symbol value by replacing its "/fragment/__overlay__" prefix with the fragment's target path. When the fragment targets the root node the target path is "/" and the result starts with "//", which __of_find_node_by_full_path() cannot resolve: symbols pointing into such fragments silently stop resolving. Drop the target path when it is the root and the tail is non-empty. A value naming the fragment root itself (empty tail) keeps the "/". Fixes: d1651b03c2df ("of: overlay: add overlay symbols to live device tree") Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-7-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 894573e2fdaeb1b15030b7eebc22615edf28a6cd Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:24 2026 -0700 of/overlay: don't leak fragment references when changeset init fails [ Upstream commit 1d62f0f2bc7edb12ed09f71203df0e47fa4efca4 ] init_overlay_changeset() stores the number of initialized fragments in ovcs->count only on full success. When find_target() or the __symbols__ lookup fails partway through, the target and overlay references taken for the fragments initialized so far are never dropped: free_overlay_changeset() bounds its cleanup loop by ovcs->count, which is still 0. Store the running count on the error path so free_overlay_changeset() puts whatever was set up. The store is guarded by ovcs->fragments because on the allocation-failure path cnt still holds the counting pass total while there is no fragments array; everywhere else cnt only counts fully-initialized fragments. Reported-by: Sashiko AI Closes: https://lore.kernel.org/20260805204009.CF3891F000E9@smtp.kernel.org Fixes: 61b4de4e0b38 ("of: overlay: minor restructuring") Assisted-by: Claude:claude-opus-4-8 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-6-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 429cebb5d1642b8a9beafccd05967cbdc20760fe Author: Karl Mehltretter Date: Wed Sep 9 08:37:44 2026 +0200 random: fix vgetrandom_opaque_params kernel-doc [ Upstream commit 703749b069d53b55f92499e088b30b031e47b8f9 ] struct vgetrandom_opaque_params contains size_of_opaque_state, but its kernel-doc describes size_per_opaque_state. This leaves the real member undescribed and adds a nonexistent member to the generated documentation. Use the member's actual name. Fixes: 4ad10a5f5f78 ("random: introduce generic vDSO getrandom() implementation") Signed-off-by: Karl Mehltretter Signed-off-by: Jason A. Donenfeld Signed-off-by: Sasha Levin commit a2f106282d42a796af72a68b550733d6012e31f9 Author: Julian Sun Date: Tue Sep 8 11:35:18 2026 +0800 nvmet: preserve device path on allocation failure [ Upstream commit 2f271b812170d4cad578bae1f91db72f3c2e36e7 ] nvmet_ns_device_path_store() frees the old path before allocating its replacement, losing the existing configuration if allocation fails. Allocate the new path before freeing the old one. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Signed-off-by: Julian Sun Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 95c8f36293c22d450c371167ad4f9a5bbadc7539 Author: Karl Mehltretter Date: Sun Aug 16 18:30:58 2026 +0200 mtd: core: call _get_device() with the master MTD [ Upstream commit 12b31d1acd20b3185bb5f0748db0cf6874c8e9d1 ] __get_mtd_device() calls the master's _get_device() callback with mtd, which may be a partition. __put_mtd_device() passes the master. This breaks gluebi partitions because gluebi_get_device() uses container_of() and therefore requires the master MTD. Pass the master to _get_device(), matching _put_device(). Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 87746be179dca4d94d73d5a323a39a87bb2e90fc Author: Matti Vaittinen Date: Mon Aug 10 10:54:32 2026 +0300 iio: accel: kionix-kx022a: Fix array boundary check [ Upstream commit 0e65412aee4f651d2c9785f542a13e4b44002a75 ] The driver performs a sanity check for an array size, when converting a register value to an array index. The check incorrectly accepts the sizeof(array) as a last index, when last valid index should be sizeof(array) - 1. Fix the check by bailing out when index >= sizeof(array). Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer") Signed-off-by: Matti Vaittinen Reviewed-by: Mehdi Djait Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 370622031b0ab4bccf370440f9e4a6122b052544 Author: SJ Park Date: Sat Oct 3 08:46:16 2026 -0700 mm/damon/core: don't skip damos_adjust_quota() while esz is not zero [ Upstream commit 52ae167ce16609c7e6fffef588b3c2c26de2db19 ] DAMOS could unexpectedly stop working when a user disables quota using the online parameters commit feature. Fix it by correcting a wrong quota unset check in damos_adjust_quota(). DAMON users could disable all quotas by unsetting time and size quotas, and removing all quota goals. The intention of disabling quotas would be making DAMOS run at full speed. When such quota disabled setup is detected, damos_adjust_quota() skips all its work. The skipped works include effective size quota (damos_quota->esz) updates and charged quota amount (damos_quota->charged_sz) resets. The intention is to avoid doing unnecessary work when quotas are disabled. However, users could do the setup while effective size quota is non-zero, by doing the disabling with the online DAMON parameters commit feature. In this case, because the effective size quota exists, DAMOS will keep working with the quota until it is fully charged. After the effective quota is fully charged, the charged quota amount (damos_quota->charged_sz) cannot be reset because damos_adjust_quota() skips it. Then, DAMOS stops working until the quota is newly set or DAMON is entirely restarted. The problem happens because damos_adjust_quota() assumes the user setup for disabling quota immediately disabled it. In reality, the quota is still working until the effective size quota is also updated to zero. Other logic for catching that uses damos_quota_is_set(), which understands the fact and therefore checks the effective size quota in addition to the user setup. Fix the issue by using damos_quota_is_set() in damos_adjust_quota() to determine if its works should be skipped. The user impact is a non-deterministic and unexpected DAMOS stop behavior. That is, users would disable quotas using the online parameters commit feature, expecting DAMOS will run at full speed. However, depending on the timing, the setup can be updated while the effective size quota is non-zero. Due to the above mentioned internal mechanism, DAMOS stops working instead of running at full speed. It is unexpected behavior. It is also non-deterministic because sometimes the setup is done when the effective size quota is zero, depending on the timing. It doesn't cause critical issues like crashes or leaks. Users can simply set a reasonable quota again, or restart DAMON. But definitely it is an unexpected and non-deterministic behavior that makes it difficult to reliably use. Also investigating the root cause of the behavior would be quite difficult. Link: https://lore.kernel.org/20260916135020.86483-1-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: Kunwu Chan Cc: # 5.19.x Signed-off-by: Sasha Levin commit 3a10517dbce1ee6d0ee0488316bd0ed0219bd328 Author: Nathan Chancellor Date: Sat Oct 3 16:41:56 2026 +0200 random: vDSO: avoid call to memset() when zeroing reserved parameter commit eb13a1ff271b0d180687eebb30611b0b276d5193 upstream. After a recent change in LLVM [1], builds with the random vDSO implementation, such as PowerPC and RISC-V, fail when checking the vDSO: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported memset() is now generated when zeroing params->reserved for some builds because LLVM has an optimization (now run in more instances) that can recognize at compile time when it is assigning a static value to a contiguous area of memory and turn that into a call to memset(). Both clang and GCC assume memset() is always available [2]. Clang has an internal fiddly hook, -max-store-memset, which we can set to a high number, to disable generating out of line memset calls [3]. Similarly, GCC has -finline-stringops=memset to do the same [4], should this issue ever hit future version of GCC. While these options wouldn't make sense for normal kernel code, it is fine for the extremely limited and intentionally compact vDSO code. Link: https://github.com/llvm/llvm-project/commit/90cebef1411617fc3eedd359bdf00cb44b1c2439 [1] Link: https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/Standards.html#index-ffreestanding [2] Link: https://github.com/llvm/llvm-project/commit/b28eeb28bea39148738dc375e8a97072a1907e64 [3] Link: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline-stringops [4] Closes: https://github.com/ClangBuiltLinux/linux/issues/2183 Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Nathan Chancellor Signed-off-by: Jason A. Donenfeld [nathan: Backport to 6.12] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit f0ece4cf97a98ccce229896719f19283b94ff23e Author: Tetsuo Handa Date: Wed Jul 9 20:27:52 2025 +0900 perf/core: Fix WARN in perf_sigtrap() [ Upstream commit 3da6bb419750f3ad834786d6ba7c9d5d062c770b ] Since exit_task_work() runs after perf_event_exit_task_context() updated ctx->task to TASK_TOMBSTONE, perf_sigtrap() from perf_pending_task() might observe event->ctx->task == TASK_TOMBSTONE. Swap the early exit tests in order not to hit WARN_ON_ONCE(). Closes: https://syzkaller.appspot.com/bug?extid=2fe61cb2a86066be6985 Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/b1c224bd-97f9-462c-a3e3-125d5e19c983@I-love.SAKURA.ne.jp Signed-off-by: Sasha Levin commit a41c95ac90f285cbe473b9606428b14518896ea4 Author: Lorenzo Stoakes (ARM) Date: Thu Sep 10 08:52:57 2026 -0400 mm/secretmem: properly account locked pages [ Upstream commit 97d34aa65c29cca85e3e9050f4c936389b38a054 ] secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream. Link: https://lore.kernel.org/20260826-secretmem-accounting-v3-1-94cb04399510@kernel.org Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: Daehyeon Ko <4ncienth@gmail.com> Closes: https://lore.kernel.org/linux-mm/20260813225328.2010303-1-4ncienth@gmail.com/ Reviewed-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Tested-by: Daehyeon Ko <4ncienth@gmail.com> Cc: Alexei Starovoitov Cc: David Hildenbrand Cc: David S. Miller Cc: Hagen Paul Pfeifer Cc: Jakub Kacinski Cc: James Bottomley Cc: Jesper Dangaard Brouer Cc: John Fastabend Cc: Liam R. Howlett Cc: Michal Hocko Cc: Stanislav Fomichev Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ adapted secretmem changes to Linux 6.12’s page-based fault handling and legacy mmap interface. ] Signed-off-by: Sasha Levin commit a84371be89c39ccc46c7af8b9eb15c448df9265f Author: Xiang Mei Date: Fri Sep 18 16:40:14 2026 -0700 ALSA: line6: reject oversized playback packets commit 61b0a5a114fa4552892da5c0ff2f42e63bf08c6b upstream. Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it. submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead. On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation. usb_submit_urb() is not a backstop. max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult(). A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write. Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams. BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229) Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002 Workqueue: events line6_startup_work Call Trace: __asan_memcpy (mm/kasan/shadow.c:106) submit_audio_out_urb (sound/usb/line6/playback.c:229) line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291) line6_stream_start (sound/usb/line6/pcm.c:194) line6_pcm_acquire (sound/usb/line6/pcm.c:337) line6_startup_work (sound/usb/line6/driver.c:728) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888100bbd400 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes inside of allocated 256-byte region [ffff888100bbd400, ffff888100bbd500) Cc: stable@vger.kernel.org Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations") Reported-by: Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260918234014.1318325-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 850810c12686f80cdf7530f4f21e0157d904f739 Author: Nguyen Ngoc Thang Date: Sat Sep 26 00:07:17 2026 +0700 ALSA: caiaq: unregister the input device when probe fails commit 0b7bd20f6379bc5e431fd74d866390f5b5b63f3c upstream. setup_card() registers the input device, whose name and phys point into struct snd_usb_caiaqdev, and then goes on to snd_card_register() and snd_usb_caiaq_control_init(). If either fails, snd_probe() calls snd_card_free(), which frees the device state but leaves the input device registered: card_free() only clears the pointer, and the input device is unregistered from snd_disconnect() alone. Reading its "uevent" attribute afterwards dereferences freed memory: BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0 Read of size 1 at addr ffff8880208f5043 by task caiaq/4967 add_uevent_var+0x183/0x3a0 input_dev_uevent+0x162/0x900 dev_uevent+0x2f1/0x870 uevent_show+0x1ca/0x3a0 ... Unregister the input device on the probe error path, as snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when no input device was registered. Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that makes snd_usb_caiaq_control_init() fail. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: stable@vger.kernel.org Reported-by: syzbot+2a123f6269da57ffefaa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2a123f6269da57ffefaa Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260925170717.22462-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 04f986fdb6c4ca367ab17aa3f2491b7528d7ddbb Author: Wentao Liang Date: Thu Sep 17 12:23:25 2026 +0000 wifi: wlcore: Fix runtime PM leak in wlcore_remove() commit a8b8881d0c1aff544fae190469d86db7b07f43a9 upstream. pm_runtime_get_sync() keeps the runtime PM usage counter elevated even when it returns an error, so the reference taken at the beginning of wlcore_remove() has to be dropped on every exit path. When the device was not initialized the function returned early without doing so, leaking the reference. Release it with pm_runtime_put_noidle() as done on the other early error paths of this driver. Fixes: fa2648a34e73f ("wlcore: Add support for runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917122325.2150910-1-vulab@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 985c000b046ca4ee11ee34ef85db500c569ef6e8 Author: Zizhi Wo Date: Sat Sep 5 14:43:37 2026 +0800 vt: skip screen update for DEC alignment test on backgroup consoles commit 0928ed9bd7946baee911efa401088697836e3b1e upstream. [BUG] Recently, we encountered a KASAN warning as follows: BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0x11f/0x140 Read of size 1 at addr ff1100015fd9f6a4 by task tty_fbcon_oob/1239 CPU: 7 UID: 0 PID: 1239 Comm: tty_fbcon_oob Not tainted 7.3.0-rc1 #100 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 Call Trace: ... kasan_report+0xf0/0x120 fb_pad_aligned_buffer+0x11f/0x140 ccw_putcs+0x86c/0xa80 fbcon_putcs+0x338/0x410 do_update_region+0x21d/0x450 do_con_write+0x1e0e/0x4880 con_write+0x13/0x80 n_tty_write+0x374/0x1010 file_tty_write.isra.0+0x404/0x7a0 ... reproduce: 1) open /dev/tty0, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 8 and op.height = 16 (visible VC1) 2) open /dev/tty1, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 28 and op.height = 24 (invisible VC2) 3) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all 4) write EShash8(esc hash8) to tty1 [CAUSE] All VCs render to the framebuffer. setfont only modifies the target VC's font without resizing the framebuffer backing buffer (par->rotated.buf); the buffer is only resized for the visible VC (fbcon_do_set_font -> ... -> vc_do_resize -> update_screen). This relies on the con_should_update() check performed before every update_region(). However, the ESC # 8 path (do_con_trol -> do_update_region) omits the con_should_update() check. After changing the font size of an invisible VC, do_update_region() fills using the new font size against a buffer that was never resized, causing an out-of-bounds access. [FIX] Only push the update when the console is visible and not blanked, add the con_should_update() check in the do_con_trol() like every other call site of do_update_region() (update_region(), invert_screen(), ...). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Zizhi Wo Link: https://patch.msgid.link/20260905064337.3083103-1-wozizhi@huaweicloud.com Signed-off-by: Greg Kroah-Hartman commit 05e7c86a06a286c99da25ebfb87076a5505a8f48 Author: Maoyi Xie Date: Fri Oct 2 18:50:55 2026 -0700 rds_tcp: close NULL deref window in rds_tcp_set_callbacks commit d2bfdbb69cf87676981b1043010b6224d84c6d3a upstream. rds_tcp_set_callbacks() links a new rds_tcp_connection onto rds_tcp_tc_list under rds_tcp_tc_list_lock. It releases the lock, then assigns tc->t_sock = sock outside the lock. rds_tcp_tc_info() and rds6_tcp_tc_info() walk rds_tcp_tc_list under the same lock. Both dereference tc->t_sock->sk without a NULL check. A reader can acquire rds_tcp_tc_list_lock between the writer's spin_unlock and the t_sock store. It then sees a list entry whose t_sock is NULL. The dereference of tc->t_sock->sk is a NULL access. Move tc->t_sock = sock inside rds_tcp_tc_list_lock, before list_add_tail. A reader holding the lock then observes the linkage and the t_sock store together. The restore path is safe. rds_tcp_restore_callbacks() does list_del_init inside the lock. The matching tc->t_sock = NULL after unlink is harmless to readers holding the lock. Fixes: 70041088e3b9 ("RDS: Add TCP transport to RDS") Suggested-by: Simon Horman Signed-off-by: Maoyi Xie Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260512142807.1855619-1-maoyi.xie@ntu.edu.sg Signed-off-by: Jakub Kicinski [ achender: resolved context conflict; tc->t_rtn initialization is not present in this tree ] Signed-off-by: Allison Henderson Signed-off-by: Sasha Levin commit 58b23fc9fb580432470d6c5da3c1e5660dba9fbc Author: Jiangshan Yi Date: Fri Oct 2 14:55:45 2026 +0000 smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions commit b8e5dc4f95e5484159b343903f302eb6d783f2e6 upstream. When a file has the setuid or setgid bit set and is written to, the VFS strips those bits and issues a setattr with ATTR_KILL_SUID/ATTR_KILL_SGID together with an ATTR_MODE carrying the already-cleared mode. Both cifs_setattr_unix() and cifs_setattr_nounix() unconditionally dropped ATTR_MODE in that case: /* skip mode change if it's just for clearing setuid/setgid */ if (attrs->ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) attrs->ia_valid &= ~ATTR_MODE; This is fine for the default mount, where the mode is only emulated via the DOS read-only attribute and cannot represent the setuid/setgid bits anyway. However, with the "cifsacl" or "modefromsid" mount options the mode is stored on the server through an ACL (id_mode_to_cifs_acl()), with the SMB3.1.1 POSIX extensions the mode is sent to the server directly, and with the SMB1 Unix extensions (cifs_setattr_unix) the mode is sent via CIFSSMBUnixSetPathInfo(). In all those cases dropping ATTR_MODE means the cleared mode is never pushed to the server, so the setuid/setgid bit survives the write. This is a security issue: on local filesystems the setuid bit is stripped when a file is written, but over these cifs.ko mounts the bit persists on the server, potentially allowing an unexpected privilege escalation on subsequent execution. Fix this in two places: 1. cifs_setattr_nounix(): only take the "skip mode change" shortcut when the mode is emulated via the DOS read-only attribute (i.e. neither cifsacl/modefromsid nor the SMB3.1.1 POSIX extensions are in effect), so that the cleared mode is propagated to the server in the ACL / POSIX cases. 2. cifs_setattr_unix(): this function is only called when Unix extensions are in effect, so the mode is always stored on the server. Remove the shortcut entirely so that the cleared mode is always pushed. Fixes: d32c4f2626ac ("CIFS: ignore mode change if it's just for clearing setuid/setgid bits") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ Backport note for 6.12: no sbflags local exists here, so test cifs_sb->mnt_cifs_flags directly (same flag bits); uses existing "bool posix". ] Signed-off-by: Bjoern Doebel Assisted-by: opencode:kimi-k3 Signed-off-by: Sasha Levin commit 538fe5efaa9704ad820ba34b4f9df135ca873d79 Author: Zhichen Wang Date: Tue Aug 25 21:50:54 2026 +0800 virt: vmgenid: set driver_data before registering notification handlers commit 9f8139c6145cf17d690d6c414d43b4c0bef632fb upstream. Both probe paths register their notification handler before assigning driver_data, which the handler dereferences. In the devicetree path, the notification IRQ can fire as soon as devm_request_irq() registers the handler: the interrupt may already be pending at probe time, for example when a VMM injects the generation-changed notification while restoring a guest from a snapshot that was taken before the driver had probed (Firecracker does exactly this on snapshot restore). The IRQ is also requested with IRQF_SHARED, so another device sharing the line can trigger the handler just as early. The handler then calls vmgenid_notify(), which dereferences the still-NULL driver_data and panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none) Hardware name: linux,dummy-virt (DT) pc : vmgenid_notify.isra.0+0x24/0x8c lr : vmgenid_of_irq_handler+0x14/0x34 Call trace: vmgenid_notify.isra.0+0x24/0x8c (P) vmgenid_of_irq_handler+0x14/0x34 __handle_irq_event_percpu+0x44/0x1bc handle_irq_event+0x4c/0xb4 handle_fasteoi_irq+0xf8/0x1f8 The ACPI path has the same ordering problem: the handler is installed with acpi_install_notify_handler() before driver_data is assigned. ACPI notifications are dispatched asynchronously from a workqueue, so the window is narrow, but a notification arriving between the two calls hits the same NULL dereference. Assign driver_data before registering the handlers. The state is fully initialized at that point, so the handlers are safe to run. Should registration fail, the probe error path leaves no dangling pointer behind: the driver core clears driver_data in device_unbind_cleanup(). Fixes: 7b1bcd6b50a6 ("virt: vmgenid: add support for devicetree bindings") Fixes: e07606713a90 ("virt: vmgenid: change implementation to use a platform driver") Cc: stable@vger.kernel.org Signed-off-by: Zhichen Wang Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit a03d0c64cd827a622578623a78defd66b6593b82 Author: Surendran Kanagaraj Date: Fri Sep 18 00:07:31 2026 +0000 tpm: Disable TPM on null key name mismatch commit 015fb29a748342a186f37b602ac70017098c8251 upstream. The null key name check exists to protect against TPM reset attacks, so a mismatch should stop the device from serving further requests. Currently it does not disable the chip when it finds a mismatch. The mismatch is logged: tpm tpm0: null key integrity check failed but the chip keeps serving commands: / # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ... tpm2_load_null() where the null key name check is run sets the chip as disabled only if the rc is non zero. When the mismatch is seen, rc is zero at that point and it returns success. The other issue is that the caller expects the null key handle to be populated when the function returns 0 which it does here without writing the handle and proceeds assuming the null key handle is valid. During the test, I noticed that tpm2_start_auth_session() uses the uninitialized stack value as the key handle since tpm2_load_null() returns 0 despite the integrity failure and proceeds with TPM2_CC_START_AUTH_SESS with this value as salt key handle. Set rc to -ENODEV on the mismatch. The error path then disables the chip and returns the correct code to the caller. Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name of the re-created null key. The chip is now disabled on the mismatch. Fixes: cc7d8594342a ("tpm: Rollback tpm2_load_null()") Fixes: 423893fcbe7e ("tpm: Disable TPM on tpm2_create_primary() failure") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: LLM Signed-off-by: Surendran Kanagaraj Link: https://lore.kernel.org/r/20260918000731.48657-1-surenkj@amazon.com Reviewed-by: Gunnar Kudrjavets Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit e8f972b1759d26bbefe4c524caae1ed7c8a593bd Author: Jun Yang Date: Sat Sep 26 17:55:15 2026 +0800 sctp: check RCV_SHUTDOWN after the sendmsg connect wait commit 4f1da630d13de0370e2f6361f961f1c8b384af1c upstream. sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue ABORT can then be processed from the socket backlog and unlink the association. If a concurrent shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead. Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue with a dangling pointer. Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before using the association again. The check only accesses the socket, so it needs no additional association reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may already have been destroyed. Keep sctp_wait_for_connect() unchanged to preserve its behavior for the connect() caller. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Cc: stable@vger.kernel.org Reported-by: TencentOS Corvus AI Signed-off-by: Jun Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260926095606.68601-1-juny24602@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c02aa67ea34a826c2cb1aa65d77cf32fafb7eec3 Author: Runyu Xiao Date: Wed Sep 2 16:03:18 2026 +0800 rtc: spear: initialize IRQ state before requesting alarm IRQ commit 055ef5ce9f67a6a3a1363fa663007f8196cc0fb8 upstream. devm_request_irq() enables the interrupt before it returns, so the handler may run while probe is still initializing the device. Initialize the MMIO address and spinlock before requesting the alarm IRQ. Fixes: 0942a71e435f ("rtc: add support for spear rtc") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260902080318.3498434-1-runyu.xiao@seu.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 6bb55381daf1a1bed0657189a1396e7467712525 Author: Aamir Ahmed Date: Sat Sep 5 19:38:08 2026 +0100 rtc: ac100: Assign .num before accessing .hws commit 6a4117eee82dd85f11bf898bf66026764011eeb6 upstream. Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in ac100_rtc_register_clks() due to .num being assigned only after every clkout clock has been stored in .hws[]. With CONFIG_UBSAN_BOUNDS and a compiler that implements __counted_by (GCC 15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report during probe, and with CONFIG_UBSAN_TRAP the first store traps. Initialize .num with AC100_CLKOUT_NUM, the number of elements .hws[] was allocated with, right after the allocation. That is the value the loop counter ends up at on the success path anyway, so the provider's behaviour is unchanged. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Chen-Yu Tsai Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/AS8P251MB00013E724A77A355668B6CCEC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit be12b221c0301111eeb023be04add3c6ad7c21fe Author: Ilkka Lappeteläinen Date: Fri Sep 25 15:48:29 2026 +0300 net/packet: prevent TX_RING byte count overflow commit 2cf81fc9505b148b1b70068303ea6ea4b1212403 upstream. tpacket_snd() drains every SEND_REQUEST frame in a TX ring and adds each valid packet length to the signed int len_sum. Userspace can recycle completed frames concurrently, so a single blocking send call is not bounded by the ring size. After enough successful transmissions len_sum wraps into the negative range. In particular, 65536 65535-byte frames followed by a 65007-byte frame produce 0xfffffdef, or -EIOCBQUEUED. sock_sendmsg_nosec() treats that as an impossible return and triggers a BUG. On systems configured to panic on oops, a CAP_NET_RAW holder can panic the host kernel. Stop before the next frame would make the byte count exceed INT_MAX. The positive short count leaves that frame pending for a later send call. A two-thread TPACKET_V2 reproducer triggered the BUG on an arm64 build of Linux 7.3-rc4. With this change, the same reproducer returned the expected positive short count without an oops. Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Cc: stable@vger.kernel.org Signed-off-by: Ilkka Lappeteläinen Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260925124829.6595-1-ilkka.lappetelainen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 64ac0cb574c740bf723affb79b646eeba920db6b Author: Aohan Mei Date: Thu Sep 10 16:33:26 2026 +0800 netfilter: nft_flow_offload: drop flowtable reference on init error path commit 747928b5d4ff8c8de55138a54c13980e4bb88578 upstream. nft_flow_offload_init() bumps the flowtable use count with nft_use_inc() before calling nf_ct_netns_get(). When the latter fails, the error is returned as-is and the reference is leaked. The upper layers do not balance it either: nf_tables_newexpr() clears expr->ops when the expression init callback fails, so the nft_expr_more() iteration in nft_rule_expr_deactivate() and nf_tables_rule_destroy() stops right before the failed expression and its ->destroy callback, which would drop the reference, never runs. Each failed rule addition therefore leaks one flowtable reference and the flowtable can no longer be removed: NFT_MSG_DELFLOWTABLE keeps reporting -EBUSY even though no rule references it. Save the nf_ct_netns_get() return value and undo the nft_use_inc() when it fails, restoring the inc/dec pairing within nft_flow_offload_init() itself. Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 2f507a48f7a46fb87e63bab6948ea805e544fc55 Author: Alireza Asgari Date: Thu Sep 24 13:00:24 2026 +0000 net: fix checksum offsets in skb_splice_from_iter() commit febec6a7076499d16b37f556724a942633a270a6 upstream. skb_splice_from_iter() appends multiple page fragments before updating skb->len. However, skb_splice_csum_page() uses that unchanged length as the offset for every fragment checksum. If bytes already appended during the call have an odd total length, a later fragment's checksum is combined with the wrong parity. For example, prime a UDP socket with sendto(MSG_MORE) and splice two distinct pipe buffers containing "abc" and "DEFGH". Uncorking reports success, but the receiver discards the packet for a bad checksum. This also affects IPv6 and fragments beginning near a page boundary. Pass the initial skb length plus the bytes already spliced to the checksum helper. Keep the existing final length update and partial-progress error handling unchanged. CHECKSUM_PARTIAL does not use this helper and remains unaffected. Fixes: 2e910b95329c ("net: Add a function to splice pages into an skbuff for MSG_SPLICE_PAGES") Cc: stable@vger.kernel.org Signed-off-by: Alireza Asgari Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-1-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c08a54df9d33dcd6ff089adc9434b2c008af3a39 Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:23 2026 -0700 of/overlay: only treat a positive changeset id as registered commit 44081d708b5b885487bac792db78324b7b4c267d upstream. of_overlay_fdt_apply() stores the idr_alloc() return value in ovcs->id before checking it. On failure the stored id is negative, free_overlay_changeset()'s "if (ovcs->id)" check passes, idr_remove() is called with a negative id and list_del() runs on ovcs->ovcs_list, which is not initialized until after the id allocation. An allocation failure at that point dereferences NULL. Make free_overlay_changeset() treat only a strict-positive id as registered. The rest of the function already copes with a partially-initialized ovcs, so the error path stays a plain goto err_free_ovcs. Fixes: 61b4de4e0b38 ("of: overlay: minor restructuring") Cc: stable@vger.kernel.org Suggested-by: Geert Uytterhoeven Assisted-by: Claude:claude-fable-5 [Claude Code] Reviewed-by: Geert Uytterhoeven Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-5-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit d5151496a0a2b19c9c0c7b0ebf86b3de55a8fa3a Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:22 2026 -0700 of/overlay: put property on deadprops only after changeset add succeeds commit 814f2da6995772c07a7c9c2cc6028b6e3f3ecc9c upstream. add_changeset_property() links a new property of a not-yet-live target node into the node's deadprops list before handing it to of_changeset_add_property(). If that fails, the error path frees the property but leaves the freed pointer linked in deadprops, and of_node_release() frees it a second time when the aborted overlay's node is released. Record the changeset entry first and link the property into deadprops only on success. of_changeset_add_property() never looks at the node's property lists, so the order of the two steps is otherwise immaterial, and the error path frees a property that nothing references. Fixes: f96278810150 ("of: overlay: set node fields from properties when add new overlay node") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-4-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 8745c07f654ea5e469f04c50fc7a0636beef930e Author: Wentao Liang Date: Thu Sep 17 12:42:47 2026 +0000 of/irq: Fix remaining refcount leaks in of_irq_init() commit 30724547b221e0e670ddfef140fc7d816b2aaec6 upstream. Successfully initialized controllers are moved to intc_parent_list, but the final cleanup only frees the descriptors. The device node references taken with of_node_get() and the interrupt parent references are therefore leaked on the normal return path. Drop both before kfree(), as the intc_desc_list cleanup already does. Fixes: 8363ccb917c6 ("of/irq: add missing of_node_put") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917124247.2151674-1-vulab@iscas.ac.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 985a568171e7bdba6dcde3420d0e5bb515813457 Author: Leon Hwang Date: Wed Sep 30 13:36:18 2026 +0800 kprobes: Skip disarmed probes when checking optkprobe overlap commit 7a39c732a22ec4a369af9e19fbe3d666ec83eec4 upstream. On x86, an optkprobe at A replaces five bytes with a jump. If a disabled probe B is at A+2, get_optimized_kprobe() stops at B when arming a new probe C at A+4. It leaves A optimized: A A+1 A+2 A+3 A+4 A's jump | e9 | d0 | d1 | d2 | d3 | after C | e9 | d0 | d1 | d2 | cc | The INT3 for C overwrites the last byte of A's jump displacement, so execution can jump to the wrong address. B can have prepared optinsns while disarmed, but has no jump to unoptimize. Continue past disarmed and unprepared probes to find the active optimized probe before arming a probe in its jump. Link: https://lore.kernel.org/all/20260930053618.104498-1-leon.hwang@linux.dev/ Fixes: afd66255b9a4 ("kprobes: Introduce kprobes jump optimization") Cc: stable@vger.kernel.org Signed-off-by: Leon Hwang Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 8b85ef0f561039e249c3f883c5280a1449c6dbee Author: Benjamin Tissoires Date: Tue Sep 15 17:46:57 2026 +0200 HID: bpf: cast size to ssize_t when checking hid_bpf_hw_request commit 3afefbfe55c2a8a0c4bdf6f4cc1f773da120027c upstream. As reported by Sashiko: If a transport driver encounters a hardware error and returns a negative error code such as -EPIPE, ret is implicitly promoted to size_t when compared against size. This causes the negative error code to evaluate as a large positive number, making the (ret > size) condition true. This silently converts the hardware error into a success return value and copies the unmodified buffer back, which could leave BPF programs operating on uninitialized or stale data. Fix this by casting size into ssize_t to return the actual negative error code. Link: https://lore.kernel.org/all/20260904130354.A79471F00A3D@smtp.kernel.org/ Fixes: 2b658c1c442e ("HID: bpf: prevent buffer overflow in hid_hw_request") Cc: stable@vger.kernel.org Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 304960900991157e6883bdf0b39782b690545ee8 Author: Jérémy Jean Date: Tue Sep 22 20:27:35 2026 +0000 audit: fix exe mark UAF in kill_rules() commit aa650d87a498844060eecb1d336f4d46f4d1b0b3 upstream. kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait. Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Ricardo Robaina Tested-by: Ricardo Robaina Reviewed-by: Bradley Morgan Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit e125d930505b92c05478fa1853bd46dbed12955e Author: Takashi Iwai Date: Tue Sep 29 16:41:26 2026 +0200 ALSA: usb-audio: Apply IGNORE_CTL_ERROR quirk to all Audient devices [ Upstream commit a154f7b9f197b3d5e41fa3ad62083f5aa93b1fe8 ] Faaris reported a problem with Audient EVO4 device and it turned out to be a regression by the recent fix commit 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks"). It exhibited that the hardware gives errors at accessing the mixer unit 10 on certain channels, and the change above made it a fatal error. We had already a quirk for Audient iD14 to work around such errors from the mixer controls, and we can simply apply the same for EVO4. OTOH, it's highly possible that other Audient devices suffer from the same issue; they must be using similar firmware, after all. So, in this patch, we apply the quirk generically to all devices with the vendor ID Audient (2708), instead. Ignoring the control error isn't usually less critical than overreaction to the firmware misbehavior. Fixes: 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks") Reported-and-tested-by: Faaris Ansari Closes: https://lore.kernel.org/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@mail.gmail.com Cc: Link: https://patch.msgid.link/20260929144132.1521617-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7f740fe8c37d51598339a33739f1481a3aea6dce Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:26 2026 +0000 neighbour: Skip default parms when resumed in neightbl_dump_info(). [ Upstream commit 979aabdad8dd03394467ee484a1a70f3d40b19ba ] neightbl_dump_info() calls neightbl_fill_info() in each loop to render the default parms. If there are many devices and neightbl_fill_param_info() failed, neightbl_fill_info() is called again when the dump resumes: # ynl --family rt-neigh --dump getneightbl --output-json | jq '.[] | {name: .name, ifindex: .parms.ifindex}' ... { "name": "ndisc_cache", "ifindex": null } ... { "name": "ndisc_cache", "ifindex": 6 } { "name": "ndisc_cache", "ifindex": null } { "name": "ndisc_cache", "ifindex": 5 } Let's skip neightbl_fill_info() if it is already called in neightbl_dump_info(). Note that we cannot use !neigh_skip instead of !default_skip because default_skip == 1 && neigh_skip == 0 could be true if the first neightbl_fill_param_info() fails. Also, nidx must be cleared at the end of each table loop; otherwise, if neightbl_fill_info() for a subsequent table fails, the leftover nidx from the previous table would be saved in cb->args[1], resulting in erroneously skipping parms of the subsequent table in the next dump. Fixes: c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-5-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c9d5b8a96d6b93eb24e07b4163c89341ba29bd1 Author: Darrick J. Wong Date: Wed Sep 30 13:34:25 2026 -0400 xfs: fix cursor and pointer handling when recovering iunlink buckets [ Upstream commit 65f39d09d73718611cee40399179323b5d4ead00 ] LOLLM pointed out a bug in xlog_recover_iunlink_bucket: 1. We don't null out prev_ip after releasing it, which can lead to UAF problems if the inodegc flush call in the loop fails. at which point I noticed even more bugs: 2. If the inodegc flush inside the loop fails, we also leak @ip. 3. We set prev_agino to agino having already advanced agino, which results in inodes with i_prev_unlinked set to itself. 4. If we exit the bottom of the loop with prev_ip set, then prev_ip aliases ip and we also set its i_prev_unlinked to itself. Bugs 3 and 4 introduce loops into the unlinked list, though these loops don't surface because we immediately flush each unlinked inode after loading it. Fix all of these issues. Cc: stable@vger.kernel.org # v6.0 Fixes: 04755d2e5821b3 ("xfs: refactor xlog_recover_process_iunlinks()") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino [ Replaced unavailable xfs_agino_to_ino() with the existing XFS_AGINO_TO_INO() macro. ] Signed-off-by: Sasha Levin commit 2cb07d1a6a30283dbfc809c8036bc1fd103d59fa Author: Zihan Xi Date: Wed Sep 30 13:58:25 2026 -0400 smb: client: close completed creates on compound wait errors [ Upstream commit 6c5c547f037bc18f0b8d0b5db5a648f8f630ce85 ] compound_send_recv() waits for responses in order. If a later wait is interrupted, or if a later MID fails during response synchronization, an earlier CREATE may already have opened a remote handle. The earlier mid is then released without invoking handle_cancelled_mid(), leaving the remote handle open because no FID was copied to the caller. Mark completed earlier mids as cancelled when a compound wait or MID synchronization aborts. Keep their response buffers attached while the MIDs are synchronized, and transfer them only after synchronization of the processed responses, so the release path can inspect successful CREATE responses and queue SMB2_close() after a later failure. Account for a remote open only after the close work is allocated and before it is queued, since the caller has not yet updated num_remote_opens. Mark the create+close compound used by smb2_unlink() so it is not closed again. Non-CREATE responses and compounds that already include a close keep their existing behavior. Fixes: e0bba0b85481 ("cifs: add compound_send_recv()") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara [ replaced the upstream cancellation helper with inline loops using midQ and MID_WAIT_CANCELLED under server->mid_lock. ] Signed-off-by: Sasha Levin commit e0e8b70207eaf27aee0a05ec5bf2d1b6bcb004d1 Author: Aldo Ariel Panzardo Date: Wed Sep 30 11:31:16 2026 -0400 Bluetooth: ISO: release unused CIS holds after channel attach [ Upstream commit 0fcd4dad555c96e0bd3a1b8c569f989be85c7341 ] hci_bind_cis() and hci_connect_cis() return one hci_conn hold for the ISO layer. A new channel association consumes that hold, which is eventually released by iso_conn_free(). There are two cases where iso_chan_add() does not create an association: it returns success when the socket is already attached to the same iso_conn, and it returns -EBUSY when another socket is attached. The hold returned for the current call is unused in both cases. This occurs when deferred setup calls iso_connect_cis() again for its existing socket, or when another socket attempts to reuse the CIS. Detect the idempotent case while the connection is locked and release the unused hold after iso_chan_add(). Also release it on -EBUSY. Do not drop it for other errors: a newly allocated iso_conn releases the transferred hold when its last temporary reference is put. Fixes: 69997d50ec57 ("Bluetooth: ISO: handle bound CIS cleanup via hci_conn") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 42c8bd6ac81e21200bb90f1eaf43d19352eec6d7 Author: SeungJu Cheon Date: Wed Sep 30 11:31:15 2026 -0400 Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths [ Upstream commit f958c7805b18e9d69f6b322b231ecee46ec6f331 ] Several iso_pi(sk) fields (qos, qos_user_set, bc_sid, base, base_len, sync_handle, bc_num_bis) are written under lock_sock in iso_sock_setsockopt() and iso_sock_bind(), but read and written under hci_dev_lock only in two other paths: - iso_connect_bis() / iso_connect_cis(), invoked from connect(2), read qos/base/bc_sid and reset qos to default_qos on the qos_user_set validation failure -- all without lock_sock. - iso_connect_ind(), invoked from hci_rx_work, writes sync_handle, bc_sid, qos.bcast.encryption, bc_num_bis, base and base_len on PA_SYNC_ESTABLISHED / PAST_RECEIVED / BIG_INFO_ADV_REPORT / PER_ADV_REPORT events. The BIG_INFO handler additionally passes &iso_pi(sk)->qos together with sync_handle / bc_num_bis / bc_bis to hci_conn_big_create_sync() while setsockopt may be mutating them. Acquire lock_sock around the affected accesses in both paths. The locking order hci_dev_lock -> lock_sock matches the existing iso_conn_big_sync() precedent, whose comment documents the same requirement for hci_conn_big_create_sync(). The HCI connect/bind helpers do not wait for command completion -- they enqueue work via hci_cmd_sync_queue{,_once}() / hci_le_create_cis_pending() and return -- so the added hold time is comparable to iso_conn_big_sync(). KCSAN report: BUG: KCSAN: data-race in iso_connect_cis / iso_sock_setsockopt read to 0xffffa3ae8ce3cdc8 of 1 bytes by task 335 on cpu 0: iso_connect_cis+0x49f/0xa20 iso_sock_connect+0x60e/0xb40 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f write to 0xffffa3ae8ce3cdc8 of 60 bytes by task 334 on cpu 1: iso_sock_setsockopt+0x69a/0x930 do_sock_setsockopt+0xc3/0x170 __sys_setsockopt+0xd1/0x130 __x64_sys_setsockopt+0x64/0x80 x64_sys_call+0x1547/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 334 Comm: iso_setup_race Not tainted 7.0.0-10949-g8541d8f725c6 #44 PREEMPT(lazy) The iso_connect_ind() races were found by inspection. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Stable adaptation for 6.12: - Omit the PAST_RECEIVED locking hunk: this tree has neither that event path nor iso_match_sid_past(). Keep locking for the existing connect, PA sync, BIG info, and periodic advertising paths. - Fold in the connection lifetime prerequisites from aa9f7cb2bd3a2 and fdfde532ab1ca. Give each socket association its own iso_conn reference, balance temporary references at all iso_conn_add() callers, and detach hcon explicitly during teardown. Use kref_get() directly instead of adding the upstream iso_conn_hold() helper. These prerequisites let 0fcd4dad555c96e0bd3a1b8c569f989be85c7341 apply unchanged with the reference ownership it expects. Its seven-line fix is intentionally left for the target commit. Stable-dep-of: 0fcd4dad555c ("Bluetooth: ISO: release unused CIS holds after channel attach") Signed-off-by: Sasha Levin commit 80c67cc71d32ccafc89a29b669243b40d81b930f Author: Zihan Xi Date: Wed Sep 30 13:34:16 2026 -0400 smb: client: close handle after create-context parsing failure [ Upstream commit 566820af017e81497fb5e9d3ad6e7ffe2828bc8b ] SMB2_open() accounts a successful CREATE response as a remote open before parsing its create contexts. If smb2_parse_contexts() rejects malformed context data, SMB2_open() returns without closing the handle, leaving the server-side handle open and num_remote_opens elevated. Close the handle after a post-CREATE context parsing failure so the error path releases the remote resource and balances the open count. Fixes: af1689a9b770 ("smb: client: fix potential OOBs in smb2_parse_contexts()") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit c928542bf9eb9435d0c60271b8c168bbb96cce34 Author: ChenXiaoSong Date: Wed Sep 30 13:34:15 2026 -0400 smb/client: pass cifs_open_info_data to SMB2_open() [ Upstream commit 1f551e407bb49dce0bbd34ed6a499dad69e18020 ] Let SMB2_open() fill the smb2_file_all_info embedded in cifs_open_info_data directly. This removes the temporary smb2_file_all_info copy in smb2_open_file(). Signed-off-by: ChenXiaoSong Signed-off-by: Steve French Stable backport notes: - Preserve the 6.12 replay backoff initialization (cur_sleep = 1) and the existing extern declaration style in smb2proto.h. - Include the existing open-completion trace changes from 4c46b677f352d (smb: client: add oplock level to smb3_open_done tracepoint). Move the trace after create-context parsing and extend its existing event class and both callers with the oplock argument. This supplies the context required for 566820af017e to apply unchanged and keeps the trace call compatible with its declaration. No new functions are introduced. Stable-dep-of: 566820af017e ("smb: client: close handle after create-context parsing failure") Signed-off-by: Sasha Levin commit 18370648d43a03524743455262499fe171c044c1 Author: ChenXiaoSong Date: Wed Sep 30 13:34:14 2026 -0400 smb/client: use stack-allocated smb2_file_all_info in smb3_query_mf_symlink() [ Upstream commit fc8789bb57e625e5f32ac57ca2e7d3e7b7fda225 ] SMB2_open() only fills the fixed fields, so a stack-allocated smb2_file_all_info is sufficient here. Signed-off-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 566820af017e ("smb: client: close handle after create-context parsing failure") Signed-off-by: Sasha Levin commit ab74ee75380263d1b65bb07cc99a702f8a7706aa Author: Peter Ujfalusi Date: Fri Oct 2 13:23:53 2026 +0300 ASoC: SOF: ipc4/Intel: Add support for library restore firmware functionality [ Upstream commit ace9b3daf2b4778358573d3698e34cb1c0fa7e14 ] The firmware will be able to only save and restore the context related to library management. This means that even without a full context save, the libraries do not need to be re-loaded to the firmware after second or consecutive boots. This is reported via the FW_READY notification, where BIT(15) indicates: 0 - the library restore is not done 1 - library restore is done This bit is only valid if full context save is not enabled, full context save is by definition saves and restores the library related book-keeping as well. Add a new flag to tell the platform code if the libraries have been restored, no need to reload them after boot. Signed-off-by: Peter Ujfalusi Reviewed-by: Guennadi Liakhovetski Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20250619105623.4546-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0519f2b85e372666477bc4ec4a8781cb45fcc5e9 Author: Peter Ujfalusi Date: Fri Oct 2 13:23:52 2026 +0300 ASoC: SOF: ipc4-priv: Add kernel doc for fw_context_save of sof_ipc4_fw_data [ Upstream commit cec49fa47bccadb288fd984ef2a5c45e8a2e2099 ] The kernel documentation is missing entry for the fw_context_save. Signed-off-by: Peter Ujfalusi Reviewed-by: Guennadi Liakhovetski Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20250619105623.4546-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 70f1a6d935af1b983ee9c17ee50f7e99f470b472 Author: Tibor Harcsa Date: Mon Jun 29 22:34:20 2026 +0200 Bluetooth: btusb: Add IMC Networks QCA9377 to quirks table [ Upstream commit dc16388d45ecbd3be0d8c9424dbbaa2c81806578 ] Add the USB ID (13d3:3503) for the IMC Networks Qualcomm Atheros QCA9377 Bluetooth controller to the btusb quirks table. This device requires Qualcomm Rome firmware and wideband speech support to function properly; otherwise, BLE scanning fails with HCI unexpected event opcode 0x2005 errors. The device reports the following in /sys/kernel/debug/usb/devices: P: Vendor=13d3 ProdID=3503 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Tibor Harcsa Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit edb1fa1608a2d8c7e42c1d275b650a35fb74ba3c Author: Richard Fitzgerald Date: Thu Sep 10 12:44:59 2026 +0100 ASoC: sdw_utils: Set snd_soc_dai_link_ch_map.codec_ch_mask for capture [ Upstream commit 290845e151cd4e307cc1f25319583aaceb4eeb30 ] In asoc_sdw_hw_params() set the codec_ch_mask member of struct snd_soc_dai_link_ch_map for capture streams. ASoC will then pass the correct number of channels to each codec hw_params(). This prevents trying to enable more channels on the codec DP than have been allocated bitslots in the SoundWire frame, which would cause bus clash errors. In theory codec_ch_mask could also be set for playback streams, but for those the CPU is the only sender so there is no risk of bus clash. For playback streams codec_ch_mask is set to 0 to preserve the existing behavior and avoid introducing bugs. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 486dbe7efec2be19cd3625be282f7f6b34a3f2c5 Author: Jiayuan Chen Date: Wed Aug 12 14:36:11 2026 +0800 bpf, xdp: move offload check into dev_xdp_install() [ Upstream commit ad27ed7d2309419a129078d781504f486b1b469a ] bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: "ip link set xdp" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach(). Fixes: 026a4c28e1db3 ("bpf, xdp: Implement LINK_UPDATE for BPF XDP link") Signed-off-by: Jiayuan Chen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 875013d67c52f6791a27b3ba670a2af332dc26de Author: Jiakai Xu Date: Sun Jan 25 14:33:44 2026 +0000 RISC-V: KVM: Fix null pointer dereference in kvm_riscv_aia_imsic_has_attr() [ Upstream commit 11366ead4f1412befea660777576c89a1bac0c1e ] Add a null pointer check for imsic_state before dereferencing it in kvm_riscv_aia_imsic_has_attr(). While the function checks that the vcpu exists, it doesn't verify that the vcpu's imsic_state has been initialized, leading to a null pointer dereference when accessed. This issue was discovered during fuzzing of RISC-V KVM code. The crash occurs when userspace calls KVM_HAS_DEVICE_ATTR ioctl on an AIA IMSIC device before the IMSIC state has been fully initialized for a vcpu. The crash manifests as: Unable to handle kernel paging request at virtual address dfffffff00000001 ... epc : kvm_riscv_aia_imsic_has_attr+0x464/0x50e arch/riscv/kvm/aia_imsic.c:998 ... kvm_riscv_aia_imsic_has_attr+0x464/0x50e arch/riscv/kvm/aia_imsic.c:998 aia_has_attr+0x128/0x2bc arch/riscv/kvm/aia_device.c:471 kvm_device_ioctl_attr virt/kvm/kvm_main.c:4722 [inline] kvm_device_ioctl+0x296/0x374 virt/kvm/kvm_main.c:4739 ... The fix adds a check to return -ENODEV if imsic_state is NULL, which is consistent with other error handling in the function and prevents the null pointer dereference. Fixes: 5463091a51cf ("RISC-V: KVM: Expose IMSIC registers as attributes of AIA irqchip") Signed-off-by: Jiakai Xu Signed-off-by: Jiakai Xu Reviewed-by: Nutty Liu Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260125143344.2515451-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 3380151cf0ce8ad0c1d356fed51e4b69e1d28e50 Author: Darrick J. Wong Date: Wed Sep 30 13:58:00 2026 -0400 xfs: don't let memory failures leak blocks and kill repairs [ Upstream commit ab1c416d2377cdc16123ef521aac4da1c468c3d4 ] LOLLM complains that a memory allocation failure in xrep_newbt_add_blocks results in online repair leaking blocks that were previously allocated to write a new btree, but the problem is worse than that -- a limitation of the codebase is that the callers cannot undo the transaction /and/ return the error -- either you undo all changes and commit the transaction, or you error out and the filesystem goes down. However, the new btree space reservation object isn't that big (~48 bytes). Let's just do a NOFAIL allocation and the problem goes away. Cc: stable@vger.kernel.org # v6.8 Fixes: be408417630427 ("xfs: implement block reservation accounting for btrees we're staging") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino [ Changed kmalloc_obj() to kmalloc(sizeof(struct xrep_newbt_resv), ...) to preserve the branch’s existing allocation syntax. ] Signed-off-by: Sasha Levin commit ed03d547598c92a036f20e89156540995cac889a Author: Namjae Jeon Date: Wed Sep 30 12:11:59 2026 -0400 smb: client: use finish_no_open() for non-regular inodes [ Upstream commit e66cf1625ec4a3fe68346119f371def713fd0a4d ] An O_CREAT open can find an existing symlink or another non-regular inode. cifs_atomic_open() calls finish_open() on it and attaches a cifsFileInfo. Symlink inodes have no CIFS release operation, so the dentry reference held by cifsFileInfo is leaked. FMODE_OPENED also prevents the VFS from following the symlink. Track whether cifs_do_create() returned an open server handle. For non-regular inodes, close the handle if present, remove the pending open, and call finish_no_open() so the VFS can continue the lookup. Do not set FMODE_CREATED unless a regular file was opened. For O_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS's -EFTYPE check. Defer closing a legacy POSIX handle on a non-regular inode until after inode lookup. This avoids closing it again if lookup fails. Fixes: d2c127197dfc ("cifs: implement i_op->atomic_open()") Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: stable@vger.kernel.org [ replaced S_ISREG(inode->i_mode) with d_is_reg(direntry) because the older cifs_do_create() already attaches the inode. ] Signed-off-by: Sasha Levin commit d6921c514598d89d6495b9de67a32c0df26b6d67 Author: Mike Rapoport (Microsoft) Date: Thu Oct 1 14:15:18 2026 -0400 selftests/mm: hugetlb-mremap: add setup of HugeTLB pages commit a914785f6349da754e1226420bf4e51961956769 upstream. hugetlb-mremap test fails if there are no free huge pages prepared by a wrapper script. Add setup of HugeTLB pages to the test and make sure that the original settings are restored on the test exit. Link: https://lore.kernel.org/20260511162840.375890-42-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Tested-by: Luiz Capitulino Tested-by: Sarthak Sharma Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Donet Tom Cc: Jason Gunthorpe Cc: John Hubbard Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Li Wang Cc: Lorenzo Stoakes Cc: Mark Brown Cc: Michal Hocko Cc: Nico Pache Cc: Peter Xu Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton [ Backport-notes: this is a partial backport containing only the aligning of 'length' to the hugepage size. The hugepage_settings.h include line and the hugetlb_setup_default() call are omitted. Without this fix, the uffd_register() call always fails on arm64 with 64K base pages and 512 MiB default HugeTLB page size causing the test to fail with the error below as 'length' is 10 MiB and not aligned to the HugeTLB page size. # ------------------------- # running ./hugepage-mremap # ------------------------- # TAP version 13 # 1..1 # # Map haddr: Returned address is 0x7eaa40000000 # # Map daddr: Returned address is 0x7daa40000000 # # Map vaddr: Returned address is 0x7faa40000000 # Bail out! ioctl-UFFDIO_REGISTER: Invalid argument # # Planned tests != run tests (1 != 0) # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 # [FAIL] not ok 1 hugepage-mremap # exit=1 # NOTE: These hugetlb tests provide minimal coverage. Use # https://github.com/libhugetlbfs/libhugetlbfs.git for # hugetlb regression testing. # SKIP ./uffd-wp-mremap ] Signed-off-by: Luiz Capitulino Signed-off-by: Sasha Levin commit 876049f026b4dfaca0cc78ec81be0e639ca8525d Author: Marc Zyngier Date: Wed Sep 30 11:09:52 2026 -0400 KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction [ Upstream commit e5843f4effaa2ffac3e789ecd4456403564961d4 ] We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which is a Bad Idea(tm). Freeing the page tables is fair game (this is what this callback is for), but freeing the container that could still be referenced by another part of the system is not great. Instead, grow separate destructors that gets called when we tear the VM down for good. From there, we can nuke both the individual MMUs as well as the global array that points to them, safe in the knowledge that the vcpus themselves have been destroyed already. Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260911162203.1919330-3-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin commit ea242bdc29e8a8ff0e2447a64b3841114779f3af Author: Marc Zyngier Date: Wed Sep 30 11:09:51 2026 -0400 KVM: arm64: nv: Fix life cycle of the nested_mmus array [ Upstream commit 33346f8960c7bb6a3b4e273b5cfe25c5a8be349f ] The nested_mmus array holds the shadow page tables that are used when a guest is running a nested context. These structures are allocated on VCPU_INIT for whole guest, which implies that they may have to be relocated as the array grows. Should a VCPU_INIT occur whilst a vcpu is actively running an L2 and that the allocation requires relocation, that vcpu will still be running with a pointer to the previous structure, which will have been freed. Fix this by turning the array of structures to an array of pointers, which is now allocated at VM creation, sized to the absolute maximum that KVM can handle. In turn, each VCPU_INIT contributes S2_MMU_PER_VCPU to the pool. No reallocation is ever performed, and the life cycle of each object is much clearer: - the nested_mmus array is allocated in kvm_init_nested(), and freed in kvm_arch_destroy_vm() - s2_mmu structures are allocated in kvm_vcpu_init_nested(), and freed on kvm_arch_flush_shadow_all() Finally, the freeing of vcpu->arch.vncr_array is made consistent rather than being done on some failure paths, but not others. Fixes: 4f128f8e1aaa ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reported-by: Shen Yongchao Reported-by: Karl Mehltretter Suggested-by: Karl Mehltretter Acked-by: Lorenzo Stoakes (ARM) Link: https://lore.kernel.org/r/20260803224405.41468-1-kmehltretter@gmail.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260911162203.1919330-2-maz@kernel.org Signed-off-by: Oliver Upton [6.12 backport: Retain the fixed pointer array and per-vCPU MMU batches, including publication under mmu_lock and cleanup of partially initialized batches. Add the stage-2 unwind label to the existing VM initialization path without importing the newer protected-VM setup. Omit VNCR allocation, VNCR TLB accounting, E2H0 checks and the debug-exception declaration, whose support is absent here. No new functions are introduced. Keep the MMU cleanup layout needed by e5843f4effaa ("KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction").] Stable-dep-of: e5843f4effaa ("KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction") Signed-off-by: Sasha Levin commit bbeb7a42c9ea656e17ddcbdc2d7917aa853383a6 Author: Fan Wu Date: Thu Sep 17 09:03:43 2026 -0400 smb: client: fix cifsFileInfo reference leak in deferred close [ Upstream commit 5520e89a5a4f834bced64cf2ac927001cc513a40 ] When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference. deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked. Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference. This issue was found by an in-house static analysis tool. Fixes: c3f207ab29f7 ("cifs: Deferred close for files") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Signed-off-by: Paulo Alcantara [ Adjusted cifs_close() context due to missing trace_smb3_close_cached(). ] Signed-off-by: Sasha Levin commit 36d01415d881d5326a0dd3384f781cd7e69aff2d Author: Frank Sorenson Date: Mon Sep 7 09:51:39 2026 -0400 smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() [ Upstream commit 6343c1da561962688f203362d80d6a3bfa39fa1b ] coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified. Fixes: e4eb295d38b5 ("[PATCH] cifs: Handle multiple response transact2 part 1 of 2") Cc: stable@vger.kernel.org Reported-by: Shen Yongchao Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ transplanted the bounds validation to coalesce_t2() in smb1ops.c due to code relocation ] Signed-off-by: Sasha Levin