commit 2ff600d29ee478d0a8d46ef8a58afb5e038fe692 Author: Greg Kroah-Hartman Date: Thu Oct 15 11:58:20 2026 +0200 Linux 6.18.57 Link: https://lore.kernel.org/r/20261013112920.855194808@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Wentao Guan Link: https://lore.kernel.org/r/20261014123820.008483134@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit d1e095c75d12799a1cd855a399f88c89147c1eca Author: Vicki Pfau Date: Tue Oct 13 09:11:35 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() and steam_get_attributes() instead of steam_exchange_report_id() and omit coalesce_rumble_work and Ibex changes as 1d4549fd1115, fcfa7db89f7a and 0a80b4e8ec6a are not present] Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit cf71a6ee1d4e36b8e65b81c064e2797a10247280 Author: Vicki Pfau Date: Tue Oct 13 09:11:34 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 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 86724f4bcf6049c3a322f7a7b1f968210059c46a Author: Vicki Pfau Date: Tue Oct 13 09:11:33 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 05d39902539a35abb4f45384938b126f433f8270 Author: Vicki Pfau Date: Tue Oct 13 09:11:32 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 3142648c952d6811259f47cc00c9c4586135b762 Author: Kuba Piecuch Date: Tue Oct 13 09:02:26 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: applied ext/ext.c and ext/internal.h hunks to ext.c and ext_internal.h; adjusted context in sched/ext.h, sched.h and dump line. ] Signed-off-by: Kuba Piecuch Signed-off-by: Sasha Levin commit f94a12ddd3184280c4a1d0ce4c8be7d36d0a52a3 Author: Adrian Betschart Date: Mon Oct 12 18:04:20 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; 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 82ac8c4939bdbd064b4f54a580fbe4baf0d60e41 Author: Alexey Charkov Date: Mon Oct 12 19:29:21 2026 +0400 regulator: of: fill in supply names in of_regulator_bulk_get_all() [ Upstream commit e2151c29cec73f6cc70abf1c7cbc7b9b202489f5 ] of_regulator_bulk_get_all() returns an array it allocated itself, and fills in only the consumer of each entry. Every other way of getting a bulk array has the supply name set, because the caller provides it, and the core expects it to be there: regulator_bulk_enable() prints it when a supply fails to enable, so a caller that hands such an array to it dereferences uninitialised memory on that path. Copy each name into the array's own allocation, right behind the entries, so that it shares the array's lifetime and callers still have nothing extra to free. That also retires the fixed 64 byte stack buffer the names were assembled in, which is_supply_name() never bounded the copy against. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260928-b4-rk3576-reboot-mode-v1-0-65486b03bd41@flipper.net?part=3 Fixes: 27b9ecc7a9ba ("regulator: Add of_regulator_bulk_get_all") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260930-regulator-get-all-v2-1-ca82070d22f2@flipper.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 32642616a8d73596e4697e3768a5059c425ee82f Author: Chuck Lever Date: Mon Apr 27 09:50:45 2026 -0400 SUNRPC: Add Kconfig dependency on CRYPTO_KRB5 [ Upstream commit bf8672b99402abd8f21392e4ef8f15468854206d ] The rpcsec_gss_krb5 module currently contains its own Kerberos 5 crypto implementation (key derivation, encryption, checksumming) that duplicates functionality available in the common crypto/krb5 library. As a first step toward migrating to that library, add a Kconfig select so that building rpcsec_gss_krb5 pulls in the common Kerberos 5 crypto support. The per-enctype Kconfig options (AES_SHA1, CAMELLIA, AES_SHA2) remain: they continue to gate which encryption types are offered by the GSS mechanism. The individual crypto algorithm selects they carry become redundant once the migration is complete, since CRYPTO_KRB5 already selects all needed ciphers and hashes. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 69bf8d145ee1bc34b213c72d533a9efd8b1f9490 Author: Oliver Hartkopp Date: Tue Oct 13 09:43:25 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.18: 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 cf32eb20dfacfd2e92ce86ba1fece9ae5f98a7d8 Author: Darrick J. Wong Date: Wed Oct 7 10:02:27 2026 -0700 xfs: fix exchange-range-to-eof file size exchange [ Upstream commit 7dfb218c829c1acb626e0fe92c5fddb9a26a03e9 ] Norbert Szetei posted a patch containing an incomplete description of a bug in XFS_IOC_EXCHANGE_RANGE's TO_EOF flag. The bug tricks exchange-range into modifying a file so that it has shared blocks starting beyond EOF, which is never allowed because files never have written data beyond EOF, and you can only share written data blocks. This is key to all the incorrect behavior that follows. Eventually I got from Norbert a description of what's going wrong: > Fair. Here it is with physical block numbers, 4k blocks. peer is the file > that gets rewritten and file1 is the one that ends up with the flag > cleared. > > Start, nothing shared: > > peer size 4096 -> [100] > file1 size 12288 -> [200] [201] [202] > donor1 size 4096 -> [300] > donor2 size 4096 -> [400] > > 1. FICLONERANGE peer's block into file1's middle slot: > > peer size 4096 -> [100] > file1 size 12288 -> [200] [100] [202] reflink flag set > ^^^^^ both files own block 100 > > 2. XFS_IOC_EXCHANGE_RANGE file1 against donor1, file1_offset 0, > file2_offset 8192, length 0, TO_EOF. One block is exchanged, and the sizes > are exchanged with it: > > file1 size 4096 -> [200] [100] [300] reflink flag set > ^^^^^^^^^^^ still owned, now past the size > donor1 size 12288 -> [202] > > file1 says it is one block long while it still owns three. Nothing was > unmapped. file2_offset is block 2, so this exchange cannot clear a flag. > > 3. XFS_IOC_EXCHANGE_RANGE file1 against donor2, both offsets 0, length 4096. > By i_disk_size this is two one-block files exchanging everything, so > xmi_can_exchange_reflink_flags() agrees and the flag is cleared: > > file1 size 4096 -> [400] [100] [300] reflink flag CLEARED > donor2 size 4096 -> [200] > > Block 100 is still shared with peer. > > 4. pwrite(file1, 4096, 4096), which is file1's second slot, block 100. > xfs_is_cow_inode(file1) is false, so no CoW: > > peer size 4096 -> [100] same block, new contents > > Block 100 is the only one that matters here. PoC below, it reads a file > called peer in the current directory. The filesystem needs reflink and > exchange-range, which mkfs.xfs 7.x turns on by default. So yes, TO_EOF is screwing up the file size even if it's actually exchanging the data block correctly. The following is the intended behavior of XFS_EXCHANGE_RANGE_TO_EOF, as described by its manpage: "Ignore the length parameter. All bytes in file1_fd from file1_offset to EOF are moved to file2_fd, and file2's size is set to (file2_offset+(file1_length-file1_offset)). Meanwhile, all bytes in file2 from file2_offset to EOF are moved to file1 and file1's size is set to (file1_offset+(file2_length-file2_offset))." In other words, if we only exchange a portion of the file data, then we should only exchange the portion of the file size that relates to the exchanged data. Unfortunately, the code swaps the ondisk file size and the incore file sizes, which is incorrect if the caller passes in a nonzero offset. Having confused the file sizes, the PoC uses a second exchange-range call on what looks like a non-reflinked single-block file. Because the file size is set incorrectly, exchange-range thinks it's exchanging the full contents of two files and clears the reflink flag on the broken file. That enables an extending write of the broken file to rewrite the shared block that's just past EOF. This has become known colloquially as refluxfs. Once the file sizes are set correctly, the second exchange-range no longer thinks that it's doing a full-contents swap, so it won't clear the reflink flag on either of its file arguments. Norbert followed up to an earlier version of this patch with a second complaint about us not handling the i_disk_size state correctly: > The offsets are bounded against the incore i_size but subtracted from > the ondisk i_disk_size, so a file that has not been written back gives > xmi_isize1 = 0 + (0 - 12288). > > For instance, you can do: > > $ xfs_io -f -c "pwrite -q 0 4096" -c fsync file1 > $ xfs_io -f -c "pwrite -q 0 12288" \ > -c "exchangerange -s 0 -d 12288 file1" dirty > $ stat -c %s file1 > 0 > $ stat -c %i file1 > 131 > $ sudo xfs_io -r -c "bulkstat_single 131" . | grep bs_size > bs_size = 18446744073709539328 That's wrong, and the new file size update logic depends on the ondisk i_disk_size matching the incore i_size, so flush the pagecache as needed to push it upwards. Link: https://lore.kernel.org/linux-xfs/1E196589-DEBE-40AC-AFEA-D420DAAB067F@doyensec.com/ Reported-by: Norbert Szetei Cc: stable@vger.kernel.org # v6.10 Fixes: 966ceafc7a4371 ("xfs: create deferred log items for file mapping exchanges") Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 7d3b9b2c9dc57f93f36c716ab752548cb4db9900 Author: Norbert Szetei Date: Wed Oct 7 16:43:22 2026 +0200 xfs: stop exchanging reflink flags when exchanging mappings [ Upstream commit d84d6c1a7f1e2de9e601703a326a4c1b7b421943 ] When an exchange covers both files from offset 0 to i_disk_size, xmi_can_exchange_reflink_flags() assumes every mapping moved and hands the reflink flag over to the other file. That assumption is wrong. A file can still own shared blocks past i_disk_size, e.g. after EXCHANGE_RANGE_TO_EOF sets a smaller size without unmapping anything. The flag is cleared anyway, and the next write to such a block happens in place instead of CoW, corrupting the other file that shares it. Commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") fixed one instance of this. Rather than add another special case, stop moving the flags. xfs_exchmaps_ensure_reflink() already sets the flag on both inodes before the exchange, so both just keep it. Nothing sets CLEAR_INO{1,2}_REFLINK anymore. Intents logged by older kernels may still carry them; recovery already masks them off, so they stay in the log format mask and are ignored. XFS_IOC_SWAPEXT has the same problem: it moves the reflink flag from one inode to the other along with the extents. Just removing that is not enough here: the exchange path flags both inodes up front in xfs_exchmaps_ensure_reflink(), but swapext has no such step, so the inode receiving the shared extents would be left without the flag. Set it on both inodes instead, and make sure both have a CoW fork, since an inode with the reflink flag is expected to have one. The flag now stays until FALLOC_FL_UNSHARE_RANGE, xfs_scrub, or a truncate to zero removes it. Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Fixes: f0bc4d134b46 ("xfs: swap inode reflink flags when swapping inode extents") Cc: stable@vger.kernel.org # v6.10 Assisted-by: LLM Signed-off-by: Norbert Szetei Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 87655adb5ddb14effd4634c1caf9af85bf2d6a15 Author: Jiangshan Yi Date: Mon Sep 14 16:21:11 2026 +0800 xfs: remove duplicate INO1_WRITTEN check [ Upstream commit ce2b91bebc7bc0495fe3ad5ee47e4977fbb77fc5 ] Commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") duplicated commit b2d5a81dae38 ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN"), so xmi_can_exchange_reflink_flags() ended up with two identical XFS_EXCHMAPS_INO1_WRITTEN checks. The second one is dead code, since the first one already returned false. Remove it. Signed-off-by: Jiangshan Yi Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 30e08c92118cc269c1024628202a222c9b0e442b Author: Rafael J. Wysocki Date: Sat Jan 10 12:58:38 2026 +0100 ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons [ Upstream commit 57c31e6d620f132dcf610b2c52b4cdbd203c6f4a ] After starting to use platform devices for representing buttons enumerated via ACPI, acpi_mark_gpe_for_wake() is insufficient for preparing their GPEs to wake up the system from sleep because it does not change the "dispatch type" of the given GPE to ACPI_GPE_DISPATCH_NOTIFY. Subsequently, this causes acpi_enable_gpe() in __acpi_device_wakeup_enable() to fail and system suspend transitions to be aborted. Address this by updating acpi_wakeup_gpe_init() to use acpi_setup_gpe_for_wake() for buttons like for any other devices. This allows acpi_setup_gpe_for_wake() to be simplified further because buttons are not a special case in it any more, so do that as well. Fixes: 52d864019636 ("ACPI: button: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki Tested-by: Xi Pardee Link: https://patch.msgid.link/2259694.irdbgypaU6@rafael.j.wysocki Signed-off-by: Sasha Levin commit d0813c7c09dfa8a1a5990832e283045e19148138 Author: Rafael J. Wysocki Date: Mon Dec 15 15:00:57 2025 +0100 ACPI: scan: Do not mark button ACPI devices as wakeup-capable [ Upstream commit 91ba8de81bcb8cea922ee9427e54798a16dfd724 ] It is generally questionable to mark struct acpi_device "devices" as wakeup-capable because they represent firmware entities that by themselves have no wakeup capabilities. It was done for struct acpi_device "devices" corresponding to buttons because the ACPI button driver was binding to them directly, but now that corresponding platform devices are created for the buttons and they are marked as wakeup-capable by the ACPI button driver, there is no reason to continue doing it. Update acpi_wakeup_gpe_init() accordingly. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2891119.BEx9A2HvPv@rafael.j.wysocki Stable-dep-of: 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons") Signed-off-by: Sasha Levin commit 5e9c814ee4da9973544b27915166b93c173c69c3 Author: Tejun Heo Date: Wed Apr 29 09:44:16 2026 -1000 workqueue: Annotate alloc_workqueue_va() with __printf(1, 0) commit 20e81c64c905bd765e69ef07920d2b1130dc79b6 upstream. alloc_workqueue_va() forwards its va_list to __alloc_workqueue() which ultimately feeds vsnprintf(). __alloc_workqueue() already carries __printf(1, 0); the new wrapper needs the same annotation so format string checking propagates through the forwarding. Fixes: 0de4cb473aed ("workqueue: fix devm_alloc_workqueue() va_list misuse") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604300347.2LgXyteh-lkp@intel.com/ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 2d2c32b1b9e32f25214f0cbc818c4d55f7da1d0e Author: Lizhi Hou Date: Thu Feb 5 22:03:06 2026 -0800 accel/amdxdna: Fix crash when destroying a suspended hardware context commit 8363c02863332992a1822688da41f881d88d1631 upstream. If userspace issues an ioctl to destroy a hardware context that has already been automatically suspended, the driver may crash because the mailbox channel pointer is NULL for the suspended context. Fix this by checking the mailbox channel pointer in aie2_destroy_context() before accessing it. Fixes: 97f27573837e ("accel/amdxdna: Fix potential NULL pointer dereference in context cleanup") Reviewed-by: Karol Wachowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260206060306.4050531-1-lizhi.hou@amd.com Signed-off-by: Greg Kroah-Hartman commit a82142af837f67a3f0a257a6dc355448ace58926 Author: Lizhi Hou Date: Mon Dec 8 08:53:56 2025 -0800 accel/amdxdna: Fix race condition when checking rpm_on commit 00ffe45ece80160aef446d74ded906352f21dd72 upstream. When autosuspend is triggered, driver rpm_on flag is set to indicate that a suspend/resume is already in progress. However, when a userspace application submits a command during this narrow window, amdxdna_pm_resume_get() may incorrectly skip the resume operation because the rpm_on flag is still set. This results in commands being submitted while the device has not actually resumed, causing unexpected behavior. The set_dpm() is called by suspend/resume, it relied on rpm_on flag to avoid calling into rpm suspend/resume recursivly. So to fix this, remove the use of the rpm_on flag entirely. Instead, introduce aie2_pm_set_dpm() which explicitly resumes the device before invoking set_dpm(). With this change, set_dpm() is called directly inside the suspend or resume execution path. Otherwise, aie2_pm_set_dpm() is called. Fixes: 063db451832b ("accel/amdxdna: Enhance runtime power management") Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251208165356.1549237-1-lizhi.hou@amd.com Signed-off-by: Greg Kroah-Hartman commit 27f52d4089ade130cd3efd391bedcf556bf67ff1 Author: Lizhi Hou Date: Tue Oct 7 21:53:24 2025 -0700 accel/amdxdna: Resume power for creating and destroying hardware context commit e00f78679f5a3d98b650fc9397c4d358ab570725 upstream. When the hardware is powered down by auto-suspend, creating or destroying a hardware context without resuming power will fail. Call amdxdna_pm_resume_get() before requesting the hardware to create or destroy a hardware context. Fixes: 063db451832b ("accel/amdxdna: Enhance runtime power management") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20251008045324.4171807-1-lizhi.hou@amd.com Signed-off-by: Greg Kroah-Hartman commit 44e61f1834831f873af5a4fec5a5e432b929c6a2 Author: Harald Freudenberger Date: Mon Aug 3 10:33:38 2026 +0200 s390/zcrypt: Pad trailing CCA or EP11 message with zeros commit eb363254472493e3458156fc11fd56dca92f4333 upstream. The both functions xcrb_msg_to_type6cprb_msgx() and xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a kernel buffer based on the message length. But on further processing the message is supposed to be 4 byte length adjusted. Thus up to 3 bytes of uninitialized kernel memory are forwarded to further processing steps and may unwanted expose kernel memory to the crypto card firmware. This patch contains code to pad the gap between user space copied message and message buffer length sent down to further processing of the CCA or EP11 message to zeros. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 7.1+ Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 00a44ff06bcffb68b9cd7e90d2259b7d14b82b18 Author: Harald Freudenberger Date: Mon Aug 3 10:33:37 2026 +0200 s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing commit 0864a163783bff109b548266921829ea794edc93 upstream. The zcrypt_msgtype6_send_ep11_cprb() function uses fragile struct overlays to access and modify the domain field in the EP11 CPRB payload, creating maintainability and security concerns: 1. Struct overlay approach (pld_hdr) assumes fixed payload structure and doesn't validate the actual ASN.1 encoding. 2. Complex length format detection logic is error-prone and doesn't properly validate bounds at each parsing step. 3. Direct struct member access bypasses proper ASN.1 validation. Fix by replacing struct overlays with explicit ASN.1 parsing that validates each field (payload tag/length, function tag/length/value, optional domain tag/length/value) with proper bounds checking at every step. Add asn1_int_encode() helper function to safely write integer values with correct endianness conversion. This makes the code consistent with the validation pattern introduced with the rework of the xcrb_msg_to_type6_ep11cprb_msgx() function. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org # 7.1+ Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit f463f474773aa49ed1d6087d95d44cea7099fdc7 Author: Harald Freudenberger Date: Mon Aug 3 10:33:36 2026 +0200 s390/zcrypt: Improve EP11 CPRB length and overflow checks commit 17ac0bc866fc624cd05f022dcd8b730c0af11bb1 upstream. The xcrb_msg_to_type6_ep11cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Missing minimum size validation: The ep11_cprb structure and subsequent payload fields (pld_tag, pld_lenfmt) are copied from userspace without verifying sufficient buffer length. 2. Arithmetic overflow in length calculations: CEIL4 alignment could overflow, bypassing size checks and enabling buffer overflows. 3. The payload is asn1 encoded but the function just uses a simple c struct overlay to access some fields of the payload. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, and validating minimum request size and minimum reply size before copying from userspace. Do a very simple asn1 parsing of the payload up to the function value field. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org # 7.1+ Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 584400144020f40365de3972c4763da520e7280e Author: Harald Freudenberger Date: Mon Aug 3 10:33:35 2026 +0200 s390/zcrypt: Improve CCA CPRB length and overflow checks commit 35ac6754ba6da45fd193f5ce3f665f7490b830d5 upstream. The xcrb_msg_to_type6cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Integer overflow after CEIL4 alignment: Signed int variables could overflow during 4-byte boundary alignment, causing undersized buffer allocations or incorrect bounds checking. 2. Missing minimum size validation: The CPRBX structure is copied from userspace without verifying sufficient buffer length. Undersized buffers cause uninitialized memory access when reading structure fields like cprbx.cprb_len and cprbx.domain. 3. Arithmetic overflow in sum calculations: Adding control block and data block sizes could overflow, bypassing size checks and enabling buffer overflows. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, validating minimum control block size before copying from userspace, and detecting sum calculation overflows. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 7.1+ Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 7673661a8adc0bac40a3b2d7c9bf9d8fb622f5a5 Author: Breno Leitao Date: Tue Apr 28 08:10:43 2026 -0700 workqueue: fix devm_alloc_workqueue() va_list misuse commit 0de4cb473aed57ee4ba7e0551ad27bddc19fc519 upstream. devm_alloc_workqueue() built a va_list and passed it as a single positional argument to the variadic alloc_workqueue() macro: va_start(args, max_active); wq = alloc_workqueue(fmt, flags, max_active, args); va_end(args); C does not allow forwarding a va_list through a ... parameter. alloc_workqueue() expands to alloc_workqueue_noprof(), which runs its own va_start() over its ... params, so the inner vsnprintf(wq->name, sizeof(wq->name), fmt, args) in __alloc_workqueue() received the outer va_list object as the first variadic slot rather than the caller's actual format arguments. Add a new static helper alloc_workqueue_va() that wraps __alloc_workqueue() and runs wq_init_lockdep() on success, and fold both alloc_workqueue_noprof() and devm_alloc_workqueue_noprof() onto it as suggested by Tejun. The wq_init_lockdep() step is required on the devm path too, otherwise __flush_workqueue()'s on-stack COMPLETION_INITIALIZER_ONSTACK_MAP would NULL-deref wq->lockdep_map. No caller changes are required. devm_alloc_ordered_workqueue() is a macro forwarding to devm_alloc_workqueue() and inherits the fix. Two in-tree callers actively trigger the broken path on every probe: drivers/power/supply/mt6370-charger.c:889 drivers/power/supply/max77705_charger.c:649 both of which use devm_alloc_ordered_workqueue(dev, "%s", 0, dev_name(dev)). A standalone reproducer module is available at[1]. Link: https://github.com/leitao/debug/blob/main/workqueue/valist/wq_va_test.c [1] Fixes: 1dfc9d60a69e ("workqueue: devres: Add device-managed allocate workqueue") Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 5c03da745171485fd181f17b69213464f6d05f3d Author: Hao Ge Date: Wed Sep 23 14:37:59 2026 +0800 netfs: Fix missing alloc tagging of direct mempool allocations commit b78b728e21c32ec4c330b299f657fb1eb02dffc2 upstream. Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") added a mempool for the folio_queues and made the request, subrequest and folio_queue allocations distinguish between writeback and everything else. Writeback is part of memory reclaim and must not fail due to ENOMEM, so it allocates under GFP_NOFS through mempool_alloc(), which may dip into the pool's reserve and, if that runs empty, wait for elements to be returned. The GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke the pool's ->alloc() callback directly instead. The direct call, however, skips the alloc_hooks() wrapper that the mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab() and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof() and rely on current->alloc_tag having been set by the caller. With CONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to current->alloc_tag not set WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook alloc_tag was not set WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook at allocation and free time respectively, as reported when reading files on a CIFS mount. The allocations are also missing from /proc/allocinfo. Wrap the direct ->alloc() invocations in alloc_hooks() with a new mempool_alloc_noreserve() helper in include/linux/mempool.h, next to the other alloc_hooks()-wrapped macros such as mempool_alloc(). The GFP_KERNEL paths keep their failable allocation semantics, they just get tagged now. Fixes: 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") Reported-by: Erhard Furtner Closes: https://lore.kernel.org/all/0b004319-9ef7-437c-a4dd-174d6a9a83db@mailbox.org/ Tested-by: Erhard Furtner Suggested-by: Suren Baghdasaryan Cc: stable@vger.kernel.org Signed-off-by: Hao Ge Link: https://patch.msgid.link/20260923063759.34667-1-hao.ge@linux.dev Acked-by: Vlastimil Babka (SUSE) Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 22adb6751bcf95b7ac0e43fd5edb437f9e5e3ea5 Author: Eric Dumazet Date: Fri Feb 13 12:04:27 2026 +0000 net: fix backlog_unlock_irq_restore() vs CONFIG_PREEMPT_RT commit 26f29b14916964043bc25b55ad1b9f5e9a12ca53 upstream. CONFIG_PREEMPT_RT is special, make this clear in backlog_lock_irq_save() and backlog_unlock_irq_restore(). The issue shows up with CONFIG_DEBUG_IRQFLAGS=y raw_local_irq_restore() called with IRQs enabled WARNING: kernel/locking/irqflag-debug.c:10 at warn_bogus_irq_restore+0xc/0x20 kernel/locking/irqflag-debug.c:10, CPU#1: aoe_tx0/1321 Modules linked in: CPU: 1 UID: 0 PID: 1321 Comm: aoe_tx0 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:warn_bogus_irq_restore+0xc/0x20 kernel/locking/irqflag-debug.c:10 Call Trace: backlog_unlock_irq_restore net/core/dev.c:253 [inline] enqueue_to_backlog+0x525/0xcf0 net/core/dev.c:5347 netif_rx_internal+0x120/0x550 net/core/dev.c:5659 __netif_rx+0xa9/0x110 net/core/dev.c:5679 loopback_xmit+0x43a/0x660 drivers/net/loopback.c:90 __netdev_start_xmit include/linux/netdevice.h:5275 [inline] netdev_start_xmit include/linux/netdevice.h:5284 [inline] xmit_one net/core/dev.c:3864 [inline] dev_hard_start_xmit+0x2df/0x830 net/core/dev.c:3880 __dev_queue_xmit+0x16f4/0x3990 net/core/dev.c:4829 dev_queue_xmit include/linux/netdevice.h:3384 [inline] Fixes: 27a01c1969a5 ("net: fully inline backlog_unlock_irq_restore()") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260213120427.2914544-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 07861e84b766c6db8014bc34138f3be4a62aad2a Author: Ming Qian Date: Fri Mar 6 11:10:57 2026 +0800 media: verisilicon: Fix kernel panic due to __initconst misuse commit e8d97c270cb46a2a88739019d0f8547adc7d97da upstream. Fix a kernel panic when probing the driver as a module: Unable to handle kernel paging request at virtual address ffffd9c18eb05000 of_find_matching_node_and_match+0x5c/0x1a0 hantro_probe+0x2f4/0x7d0 [hantro_vpu] The imx8mq_vpu_shared_resources array is referenced by variant structures through their shared_devices field. When built as a module, __initconst causes this data to be freed after module init, but it's later accessed during probe, causing a page fault. The imx8mq_vpu_shared_resources is referenced from non-init code, so keeping __initconst or __initconst_or_module here is wrong. Drop the __initconst annotation and let it live in the normal .rodata section. A bug of __initconst called from regular non-init probe code leading to bugs during probe deferrals or during unbind-bind cycles. Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/all/68ef934f-baa0-4bf6-93d8-834bbc441e66@kernel.org/ Reported-by: Franz Schnyder Closes: https://lore.kernel.org/all/n3qmcb62tepxltoskpf7ws6yiirc2so62ia23b42rj3wlmpl67@rvkbuirx7kkp/ Fixes: e0203ddf9af7 ("media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC") Suggested-by: Krzysztof Kozlowski Suggested-by: Marco Felsch Reviewed-by: Marco Felsch Signed-off-by: Ming Qian Reviewed-by: Frank Li Reviewed-by: Krzysztof Kozlowski Cc: stable@kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a582e7391fe3557e8284d7e82cda142591dfe4d2 Author: David Howells Date: Tue Sep 15 17:21:59 2026 +0100 netfs, afs: Fix symlink reading commit c51e89c5b5db3e1927738fad7cd18b66dde68aed upstream. Fix the reading of symlinks from the cache in afs by making netfslib trim the amount read down to i_size. The problem is that afs sets the size of the iterator to the size of the buffer (PAGE_SIZE) so that the cache can round the read size up to the cache's DIO size. Note that this also impacts the reading of AFS mountpoints as they're just stored as symlinks with an odd file mode. Link: https://patch.msgid.link/3912795.1789489319@warthog.procyon.org.uk Fixes: c0410adf3da6 ("afs: Fix the locking used by afs_get_link()") Reviewed-by: Paulo Alcantara cc: Paulo Alcantara cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 4719852d14db203752bfd68b1260da4bd6e6d5cd Author: Frank Sorenson Date: Fri Jul 24 11:30:35 2026 -0500 cifs: consolidate time_last_write stamp into _cifsFileInfo_put() commit 0e3ea5445c228048f937ad5a944c27859a78f971 upstream. The time_last_write stamp was scattered across cifs_close(), smb2_deferred_work_close(), and the three drain functions in misc.c. This missed the case where background I/O holds the final reference after userspace close() returns, and required explicit maintenance at each close-path site. Move the smp_store_release() into _cifsFileInfo_put(), immediately before releasing open_file_lock. This single location covers all close paths unconditionally: normal close, background I/O dropping the final reference, deferred close via timer or external drain. The spinlock's store-release/load-acquire pairing with is_inode_writable() already provides the ordering guarantee documented in is_size_safe_to_change(). Remove the now-redundant stamps from cifs_close(), smb2_deferred_work_close(), and all six stamp sites in the misc.c deferred-close drain functions. Fixes: e8a8d54c2d50 ("cifs: prevent readdir from changing file size due to stale directory metadata") Signed-off-by: Frank Sorenson Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 8f7285d608ed0db7c9f09f341547db5ce1351090 Author: Qu Wenruo Date: Sat Jun 20 14:37:02 2026 +0930 btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock commit 690c2accacb1aca91ab8186d15dee56da8723f31 upstream. [FALSE ALERTS] There is a bug report that the warning inside invalidate_and_check_btree_folios() got triggered during btrfs/298: BTRFS info (device sdd): first mount of filesystem f9bf732a-a19b-44b9-99a7-614ddff168e2 BTRFS info (device sdd): using crc32c checksum algorithm BTRFS error (device sdd): failed to find fsid cb2fdb42-b638-4f2f-badd-4127467ba674 when attempting to open seed devices BTRFS error (device sdd): failed to read chunk tree: -2 ------------[ cut here ]------------ WARNING: disk-io.c:3342 at invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs], CPU#4: mount/125993 CPU: 4 UID: 0 PID: 125993 Comm: mount Tainted: G W OE 7.1.0-rc7-custom+ #1 PREEMPT(full) Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 Call trace: invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs] (P) open_ctree+0x1f50/0x23b0 [btrfs] btrfs_get_tree+0x89c/0xc48 [btrfs] vfs_get_tree+0x30/0x110 vfs_cmd_create+0x58/0xe8 __arm64_sys_fsconfig+0x39c/0x518 invoke_syscall.constprop.0+0x48/0x120 el0_svc_common.constprop.0+0x40/0xe8 do_el0_svc+0x24/0x38 el0_svc+0x50/0x310 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 ---[ end trace 0000000000000000 ]--- BTRFS warning (device sdd): unable to release extent buffer 365985792 owner 3 gen 17 refs 3 flags 0x5 [CAUSE] In that invalidate_and_check_btree_folios() we wait for the eb to finish its read, then check if it's only held by us and the btree inode. If not, then do a warning as it may be still held, and could cause problems. But there is a small window where the check can lead to false alerts: Thread A (Read endio) | Thread B (Unmount) ----------------------------------+------------------------------------- end_bbio_meta_read() | | The eb has one extra ref held | | by the reader, and has | | EXTENT_BUFFER_READING flag set | invalidate_and_check_btree_folios() | | | |- clear_extent_buffer_reading() | | | | |- wait_on_bit_io(); | | | The EXTENT_BUFFER_READING flag is | | | cleared | | |- if (refcount_read(eb->refs) > 2) | | The eb is held by the read, us | | and btree inode, thus it | | will trigger the warning |- free_extent_buffer() | [FIX] Introduce a helper, free_extent_buffer_clear_reading(). If the new parameter, @clear_reading, is set, we will hold the spinlock at the beginning of free_extent_buffer_clear_reading() to make sure the EXTENT_BUFFER_READING flag is cleared inside the same critical section of decreasing refs. Now free_extent_buffer() will just call free_extent_buffer_clear_reading() with @clear_reading set to false, so no behavior change. But for end_bbio_meta_read(), it will not clear_extent_buffer_reading() directly, but pass @clear_reading as true. Then inside invalidate_and_check_btree_folios(), hold the refs_lock before reading refs. So that we eliminate the race window completely. Reported-by: Su Yue Link: https://lore.kernel.org/linux-btrfs/DC0C775E-13B3-47D9-9AB2-895BB11C029D@suse.com/ Fixes: 83f7e52b7ed1 ("btrfs: warn about extent buffer that can not be released") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit fdee3570b282a6c8699aea63fa5694355e010ec9 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 e3e6779f77ab6f0a1aa80e24868d2d89f31053fe Author: Borislav Petkov (AMD) Date: Fri Oct 2 14:16:17 2026 -0700 x86/CPU/AMD: Fix AMD TLBI Erratum #1718 commit 87db7795cbaaf636ae22ae031f4906db7bb77803 upstream. The processor may fail to invalidate a TLB entry while executing an INVLPGB/TLBSYNC instruction pair. Detect the erratum and apply a software workaround when a microcode fix is not present. Fixes: 82378c6c2f43 ("x86/mm: Use INVLPGB for kernel TLB flushes") Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Rik van Riel Acked-by: Lorenzo Stoakes (ARM) Tested-by: Lorenzo Stoakes (ARM) Tested-by: Rik van Riel Cc: stable@kernel.org Link: https://patch.msgid.link/20261002211617.1001617-1-bp@kernel.org Signed-off-by: Greg Kroah-Hartman commit bf0f3412d5a0d1b0cf7f53cc53f1048ebfead175 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 4835dbcde5cc3ae37e0d0796052056b35fcae8bf 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 2594795fd832f0253826d64ff8976b8ff5fbfe9f 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 0849ecf1c65e8c153bc26cebeb215d37902d6c9d 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 3938430f0237c59ca08d6a366e7657b2b7f8d0bb 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 5b1fb3b105ff64647097493cb8f0c40b6f2f16b9 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 e241465838e2671d45c99690da9067096d75253b 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 9caa2eca5cc8372517ff36a83f321d4326abae93 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 cc18eb0e9941162c03f03f411ed7f6c339d91fa0 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 cb0d55754b4f901bacac71afab90c23fca7afe10 Author: Pavan Chebbi Date: Mon Oct 5 13:42:46 2026 -0700 bnxt_en: Re-write the BARs following any type of PCIe errors [ Upstream commit 2e52da27096d9dbc487f303bbc10d44ad837a8c4 ] Currently the driver zeroes the BARs only when fatal PCIe errors are reported so that pci_restore_state() restores it. However firmware handles both fatal and non-fatal errors the same way when it sees the slot reset resulting from the PCI_ERS_RESULT_NEED_RESET return code from the driver. This means that we must re-write the BARs post recovery even during non-fatal errors. Otherwise we will see that every MMIO access returns all-ones and the firmware appears dead. Zero-out the BARs during PCIe error recovery regardless of type of PCIe error, and make the wait after the hot reset unconditional. Disable memory decode and bus mastering before rewriting the BARs so the device doesn't decode a half-updated address, bailing out if config space is still inaccessible. Defer pci_enable_device() until after the BAR rewrite and restore, so the device isn't re-enabled while its BARs are still being rewritten, then re-enable the device and re-assert bus mastering. Guard the same Command register cleanup on the re-enable failure path against an inaccessible device. Skip re-enabling the device in bnxt_io_slot_reset() if it is already enabled, so enable_cnt does not go unbalanced. A concurrent bnxt_fw_reset_task() can also be re-enabling the same device in its ENABLE_DEV state, so guard that call the same way. Fixes: f75d9a0aa967 ("bnxt_en: Re-write PCI BARs after PCI fatal error.") Reviewed-by: Kalesh AP Reviewed-by: Scott Branden Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20261005204246.3822563-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd6a2b055dbc877f1df80acbc0b8ae0472880069 Author: Lukas Wunner Date: Thu May 7 15:04:59 2026 +0200 bnxt_en: Drop pci_save_state() after pci_restore_state() [ Upstream commit 04ae0d54c1b11a622b8b0f502675135c7d9dab61 ] Commit 383d89699c50 ("treewide: Drop pci_save_state() after pci_restore_state()") sought to purge all superfluous invocations of pci_save_state() from the tree. Unfortunately the commit missed one invocation in the Broadcom NetXtreme-C/E driver. Drop it. Signed-off-by: Lukas Wunner Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/39de1b025928d9a457976010b2324e7e99baa92a.1778158755.git.lukas@wunner.de Signed-off-by: Jakub Kicinski Stable-dep-of: 2e52da27096d ("bnxt_en: Re-write the BARs following any type of PCIe errors") Signed-off-by: Sasha Levin commit 5026c5070b82511f2230d93dae997566b27d68ce Author: Michael Chan Date: Mon May 4 14:06:08 2026 +0530 bnxt_en: Delay for 5 seconds after AER DPC for all chips [ Upstream commit 07f44433355f70fa97d4c44b4c0d2e86adc082fb ] The FW on all chips is requiring a 5-second delay after Downstream Port Containment (DPC) AER. The previously added 900 msec delay was not long enough in all cases because the chip's CRS (Configuration Request Retry Status) mechanism is not always reliable. Fixes: d5ab32e9b02d ("bnxt_en: Add delay to handle Downstream Port Containment (DPC) AER") Reviewed-by: Kalesh AP Signed-off-by: Michael Chan Signed-off-by: Pavan Chebbi Link: https://patch.msgid.link/20260504083611.1383776-2-pavan.chebbi@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2e52da27096d ("bnxt_en: Re-write the BARs following any type of PCIe errors") Signed-off-by: Sasha Levin commit f41becbee8fc6751c92874facd482ba344e728ae 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 8ef2b3ce6d1422cae0c7a0344da33beb0795bb8a 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 b18a6496495495e2dc27e525aa3315a0c59b9513 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 75e7f850cabd52e25192ec8da5ab1edd132e34dc Author: Justin Chen Date: Wed Sep 30 16:06:34 2026 -0700 net: bcmgenet: if UMAC was suspended in SW_RESET, restore it to SW_RESET [ Upstream commit 5857e5a196b069766a39ceb754736326a43bc6bc ] When the revised suspend/resume sequence was introduced this led to an edge case where the TX is left disabled in the following sequence. 1. phy link is down, so UMAC is held in reset and then network interface is WoL enabled 2. Enter suspend, bcmgenet_wol_power_down_cfg() enables UMAC_RX since MAC is in SW_RESET 4. Enter resume, UMAC_RX is left enabled. Since we only enable UMAC_TX and UMAC_RX in SW_RESET. The UMAC_TX is never enabled again on link up. The issue was hit in production and I verified the sequence keeps the TX disabled in my standalone test. I tested on an internal development board with bcm77122, but should be reproducible on any genet HW that supports power management. Fixes: 254f3239dd07 ("net: bcmgenet: revise suspend/resume") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260930230634.3132729-1-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e378bd870565980ed6b0a3ce6f0de6d9035842e7 Author: Or Har-Toov Date: Sun Oct 4 11:35:31 2026 +0300 Revert "net/mlx5: E-Switch, preserve max tx speed on vport state modification" [ Upstream commit 86b785b18f8f4a6b4a7392d1e2b29d6bb095011a ] This reverts commit ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification"). mlx5_modify_vport_admin_state() and mlx5_esw_adj_vport_modify() query the vport's current max_tx_speed before modifying its state, and write that value back, to avoid resetting it to 0 as a side effect of an unrelated admin-state change. That's unnecessary: max_tx_speed is optional in MODIFY_VPORT_STATE - FW skips writing it whenever it's 0, treating that as "not provided" rather than "reset to zero". Leaving it unset already preserves FW's current value, with no query needed. Fixes: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20261004083531.216988-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 972b9285ae530d0ecfde741ea92069b909a86196 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 8de57bfec3825effb57fe4d25da98ec3b8fda4c6 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 27748588c9310fe8a2533b0613611dff221cb429 Author: Quentin Freimanis Date: Sun Oct 4 22:28:26 2026 -0700 net: sparx5: start the TOD counters on non-PTP lan969x variants [ Upstream commit ca5012757bf027df83d51593a07656cb8c80caee ] Currently the base non-PTP-capable lan969x variants don't forward any Ethernet frames: $ ip link set eth10 up $ ip addr add 10.0.0.54/24 dev eth10 $ ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes --- 10.0.0.1 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss $ cat /proc/interrupts | grep fdma 20: 0 GIC-0 120 Level sparx5-fdma $ ip -s link show dev eth10 RX: bytes packets errors dropped missed mcast 20828 102 0 0 0 72 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0 Testing showed that starting the domain 0 TOD counter gets networking working again, but start all three for consistency with the PTP variants. Fixes: 207966787b71 ("net: sparx5: add feature support") Suggested-by: Daniel Machon Signed-off-by: Quentin Freimanis Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261005052826.14251-1-quentin@q-lab.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9993e6a0ac1b5b3101ffba702cacb9f42b9909d8 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 0bcebf2c4305cc17273a84effd5448808fb6074b 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 1194fd4c6dd1d727527b37c288e4b275012cf49d Author: Han Gao Date: Thu Oct 1 02:22:51 2026 +0800 spi: sg2044-nor: Honor SPI clock limits [ Upstream commit 61d44a2c07b2ad3f7db167f17ff2461ffe78441c ] The fixed divider ignores device and operation clock limits. Calculate the divider before each transfer so SCK does not exceed either limit. Advertise the controller maximum speed so the SPI core supplies a default when the device omits its maximum speed. Use the fastest divider when no speed limit is supplied. Fixes: de16c322eefb ("spi: sophgo: add SG2044 SPI NOR controller driver") Signed-off-by: Han Gao Link: https://patch.msgid.link/20261001-fix-sg204xspi-v2-2-014dbaf22b5e@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f3e80f5132dc4759fe578b0ab7d1966b86280ee2 Author: Han Gao Date: Thu Oct 1 02:22:50 2026 +0800 spi: sg2044-nor: Return transfer errors [ Upstream commit e130c54fbb603f9aeacf5029789b4a2c8c48f416 ] The transfer helpers return errors, but both dispatchers discard them. Return these errors to the SPI memory layer instead of reporting success. Fixes: de16c322eefb ("spi: sophgo: add SG2044 SPI NOR controller driver") Signed-off-by: Han Gao Link: https://patch.msgid.link/20261001-fix-sg204xspi-v2-1-014dbaf22b5e@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 64bb35079dcbc67901da1fe8c52c234cbcd17df3 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 ef15a51966ee1052ad2ad161df5e26189645045a 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 47c0c7a051b70d396774d5dc27b23283c28c3555 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 1bee950630df03d87e06e061701c07b64c466340 Author: Yingying Tang Date: Thu Jun 11 20:23:32 2026 -0700 Revert "wifi: ath12k: add panic handler" [ Upstream commit 05165f7b3b9ab6817fe216c24f90755b7c5e15f3 ] ath12k_core_panic_handler() is invoked via atomic_notifier_call_chain(), which runs inside an RCU read-side critical section. The current code calls ath12k_pci_sw_reset() synchronously from this context, which eventually reaches mhi_device_get_sync() and schedule_timeout(), triggering a voluntary context switch within RCU. Call trace: rcu_note_context_switch+0x4c4/0x508 (P) __schedule+0xbc/0x1204 schedule+0x34/0x110 schedule_timeout+0x84/0x11c __mhi_device_get_sync+0x164/0x228 [mhi] mhi_device_get_sync+0x1c/0x3c [mhi] ath12k_wifi7_pci_bus_wake_up+0x20/0x2c [ath12k_wifi7] ath12k_pci_read32+0x58/0x350 [ath12k] ath12k_pci_clear_dbg_registers+0x28/0xb8 [ath12k] ath12k_pci_panic_handler+0x20/0x44 [ath12k] ath12k_core_panic_handler+0x28/0x3c [ath12k] notifier_call_chain+0x78/0x1c0 atomic_notifier_call_chain+0x3c/0x5c Revert change "wifi: ath12k: add panic handler" to avoid this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Signed-off-by: Yingying Tang Tested-by: Joonhoe Kim <26rote@gmail.com> Reviewed-by: Rameshkumar Sundaram Fixes: 809055628bce ("wifi: ath12k: add panic handler") Link: https://patch.msgid.link/20260612032332.2278338-1-yingying.tang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e3f7cc4ef04d1f2a9e8b2dd3d482247a52618112 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 83ec70a640fe1425af0c4e979653aff8e9eb9b06 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 7fb2d37329c62aab05559143985c09d4c6c9593b 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 0f9afe238eeb79829f0f92f376ba3a20781caccd 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 f240282165821bb0b4b0affa8798c9a97919006f 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 0ed29ec00eb335aa355064b7c84b1565a8df3205 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 69aae4146191f88173d5b20bc42fd79e3be41b55 Author: Felix Fietkau Date: Tue Sep 1 11:22:32 2026 +0200 wifi: mt76: use ALTX queue for packets to disassociated stations [ Upstream commit 7c2e6b43c3082c2242ecfa5875b2b4b2cd06140f ] Running these packets through regular buffering queues could cause them to hang, especially when the packets were for stations that in disassoc state. Fixes: dedf2ec30fe4 ("wifi: mt76: fix queue assignment for deauth packets") Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260901092232.461379-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a18f68c1e72c856c04ed7cdccd51b300bee4418a Author: Felix Fietkau Date: Mon Mar 9 06:07:28 2026 +0000 wifi: mt76: route nullfunc frames to PSD/ALTX queue [ Upstream commit 331e766e75d2a64b5c1f38aadfcfcf31d264f43e ] ieee80211_is_data() returns true for nullfunc/QoS-nullfunc frames, so they bypass the PSD queue routing and go through the regular VO data queue. This means firmware processes them through the normal TID queue instead of the ALTX queue, which doesn't guarantee immediate transmission. Use ieee80211_is_data_present() instead, which returns false for both management frames and nullfunc/QoS-nullfunc (no payload), routing them to MT_TXQ_PSD. Firmware maps PSD to the ALTX queue, which transmits immediately without PS buffering. This only affects frames from the mt76_tx() pending path. Regular mac80211 TXQ scheduling is unchanged. Link: https://patch.msgid.link/20260309060730.87840-9-nbd@nbd.name Signed-off-by: Felix Fietkau Stable-dep-of: 7c2e6b43c308 ("wifi: mt76: use ALTX queue for packets to disassociated stations") Signed-off-by: Sasha Levin commit 9f28f504650869d41f7b3e98e4bc4547af4d5670 Author: Felix Fietkau Date: Tue Aug 18 12:58:25 2026 +0000 wifi: mt76: account non-AQL frames per peer rather than per link [ Upstream commit 752770d7a58c821c17909c3ca67f9f14ab146a40 ] The driver increments wcid->non_aql_packets when a frame goes to the hardware queue. The completion path decrements the counter again. For an MLO peer, the hardware reports the completion on the link that it used for the transmission. This link can differ from the link that the driver queued the frame on. In that case, the increment and the decrement go to different link wcids, and the count drifts upwards until it blocks the station. Keep the count on the wcid of the primary link, like the other peer-wide state. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Link: https://patch.msgid.link/20260818125825.395538-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 65b080310077cefe43a37265031fc78a51b203a4 Author: Felix Fietkau Date: Sat Aug 1 14:53:25 2026 +0000 wifi: mt76: add PS buffering support for HW-managed TIM drivers [ Upstream commit a547b414bf7ea9877456b5630573293cc0e2cae7 ] Add MT_DRV_HW_PS_BUFFERING flag for drivers where firmware controls the TIM bit based on buffered frames. Instead of blocking all TX to PS stations (which starves firmware and prevents TIM from being set), allow limited frame delivery using AQL pending airtime as the throttle. Replenish the firmware buffer on TX completion. Add mt76_sta_ps_transition() helper for drivers to call from MCU PS sync events. Link: https://patch.msgid.link/20260801145334.1166751-1-nbd@nbd.name Signed-off-by: Felix Fietkau Stable-dep-of: 752770d7a58c ("wifi: mt76: account non-AQL frames per peer rather than per link") Signed-off-by: Sasha Levin commit 12b467683be5f594ffe6aaf63cc6cb8763e22628 Author: Felix Fietkau Date: Fri Jul 24 11:54:29 2026 +0000 wifi: mac80211: add ieee80211_txq_aql_pending() [ Upstream commit 9a197e71eb7b45860e37a9f3bdf61a843781ae12 ] Add a function to allow drivers to query the pending AQL airtime for a given txq, for both unicast and broadcast. This will be used for mt76 to limit buffering in AP mode for power-save stations. Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260724115429.3921457-4-nbd@nbd.name Signed-off-by: Johannes Berg Stable-dep-of: 752770d7a58c ("wifi: mt76: account non-AQL frames per peer rather than per link") Signed-off-by: Sasha Levin commit 09c6284b21f2eef35265bfdf93c59894d64dc1b1 Author: Felix Fietkau Date: Fri Jul 24 11:54:28 2026 +0000 wifi: mac80211: add AQL support for multicast packets [ Upstream commit 836c1addd3bf42d47ca5f7a5780a7ec52abf332e ] Excessive multicast traffic with little competing unicast traffic can easily flood hardware queues, leading to throughput issues. Additionally, filling the hardware queues with too many packets breaks FQ for multicast data. Fix this by enabling AQL for multicast packets. Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260724115429.3921457-3-nbd@nbd.name Signed-off-by: Johannes Berg Stable-dep-of: 752770d7a58c ("wifi: mt76: account non-AQL frames per peer rather than per link") Signed-off-by: Sasha Levin commit aafd1724f65efb219eeea994a386176ea2fbf909 Author: David Bauer Date: Fri Jan 30 00:23:20 2026 +0100 wifi: mt76: don't return TXQ when exceeding max non-AQL packets [ Upstream commit 964f870e090e9c88a41e2890333421204cc0bdf4 ] mt76_txq_send_burst does check if the number of non-AQL frames exceeds the maximum. In this case the queue is returned to ieee80211_return_txq when iterating over the scheduled TXQs in mt76_txq_schedule_list. This has the effect of inserting said TXQ at the head of the list. This means the loop will get the same TXQ again, which will terminate the scheduling round. TXQs following in the list thus never get scheduled for transmission. This can manifest in high latency low throughput or broken connections for said STAs. Check if the non-AQL packet count exceeds the limit and not return the TXQ in this case. Schedule all TXQs for the STA in case the non-AQL limit can be satisfied again. Signed-off-by: David Bauer Link: https://patch.msgid.link/20260129232321.276575-1-mail@david-bauer.net Signed-off-by: Felix Fietkau Stable-dep-of: 752770d7a58c ("wifi: mt76: account non-AQL frames per peer rather than per link") Signed-off-by: Sasha Levin commit 0cf84535c031aa4011d18c9d874ea6b1cdd1c27c Author: Aurelien Jarno Date: Mon Oct 5 19:02:37 2026 -0600 riscv: vector: Fix output operands in context save [ Upstream commit 55b1276ef9c1c27e8a2b2c5e8ef0515b5ad0332c ] The __vstate_csr_save() inline assembly declares vcsr as an output operand while the assembly only writes vstart, vtype, and vl. Remove it as it is later saved by the C code. Fixes: d863910eabaf ("riscv: vector: Support xtheadvector save/restore") Signed-off-by: Aurelien Jarno Link: https://patch.msgid.link/20260911194218.3379486-1-aurelien@aurel32.net Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit b56f9e11ac9f1ad961fe7f378942db506d84be69 Author: Troy Mitchell Date: Mon Oct 5 19:02:37 2026 -0600 riscv: vector: Fix data pointer constraints in context save/restore [ Upstream commit 572b25f3a6453d8e7fc28cc0cefe41ed15be166c ] The standard vector save/restore asm advances datap but declares it as input-only. An inlined caller reusing the original pointer may therefore use the advanced address instead. Declare datap as read-write so the compiler can preserve the original pointer when needed. Fixes: 03c3fcd9941a ("riscv: Introduce struct/helpers to save/restore per-task Vector state") Signed-off-by: Troy Mitchell Reviewed-by: GUO Ren (XuanTie) Reviewed-by: Aurelien Jarno Reviewed-by: Andy Chiu Link: https://patch.msgid.link/20260908-riscv-vector-asm-fix-v1-1-147f314efb2b@linux.dev Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 2c77af8bb5dc13591bee2898b3cae5de80105118 Author: Jakub Kicinski Date: Wed Sep 30 18:25:59 2026 -0700 net: make dev_xdp_sb_prog_count() see programs attached through a link [ Upstream commit d333c8bca6dc3c5e978f6698d39dd799f3b0dc8d ] ethtool refuses to enable tcp-data-split on a device running a single-buffer XDP program (which can't deal with the payload landing in a separate buffer). dev_xdp_sb_prog_count() only looks at xdp_state[].prog though, ignoring bpf_link integration. Get the prog pointer from dev_xdp_prog(), which will consult both. bpf_xdp_link_update() needs a bit of a touch-up, too, since ethtool calls dev_xdp_sb_prog_count() with just the instance lock (for ops-locked devices) - we now have to make sure the link updates happen under that lock. Spotted by AI while reviewing the XDP propagation series, verified and tested on netdevsim with a C test along these lines: link = bpf_program__attach_xdp(prog, ifindex); system("ethtool -G eth0 tcp-data-split on") Fixes: 197258f0ef68 ("net: ethtool: add hds_config member in ethtool_netdev_state") Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20261001012559.297751-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63bc3cf8d7dd94e9c277055f1b4a61dafc7dfb3f Author: Alan Previn Date: Tue Sep 29 12:20:37 2026 -0700 drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximums [ Upstream commit e7ed652b1312ffcb9ea2153946615856b5097c78 ] Check for overflow in udelay use in __xe_mmio_wait32 and avoid growing delays becoming intollerably large by capping the in-loop wait time. v7: - Change assisted-by to "LLM" (Rodrigo). - Move the max-wait macro to outside the function (Rodrigo). v6: - Fix commit message to remove items dropped in v5. Fix the use of MAX_UDELAY_MS for microsecond unit. (Shasiko review). v5: - Simplify: don't introduce additional redesign and use min_t with a backoff to cap wait. (Rodrigo). v4: - Simplify using poll_timeout_us and poll_timeout_us_atomic and update all callers to never use a param for atomic (Jani) v3: - Use div64_s64 kernel API for 32-bit vs 64-bit division. v2: - Fixed checkpatch failure. - Added helper for 64-bit DIV_ROUND_UP on 32-bit CPU (Shasiko review). Fixed bug max range in usleep_range(Shasiko review) Fixes: 5c09bd6ccd41 ("drm/xe/mmio: Move xe_mmio_wait32() to xe_mmio.c") Signed-off-by: Alan Previn Reviewed-by: Rodrigo Vivi Assisted-by: LLM Link: https://patch.msgid.link/20260929192037.2233429-2-alan.previn.teres.alexis@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 70dab9ee7d620e6018a64798aed065d14e9baed1) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 36d7e2da7a87385310c9ef6a58ce061c7900a394 Author: Filipe Manana Date: Fri Sep 25 17:12:45 2026 +0100 btrfs: fix lost error return value in btrfs_listxattr() [ Upstream commit 41c8899d59898f6fa51ceebd2b6e55257191a8ee ] If the input buffer does not have enough space to store the current xattr, we set 'iter_ret' to -ERANGE and then do "break", but that only exits the while loop over the xattrs in the current btrfs_dir_item, and then we continue the btrfs_for_each_slot() iteration, which overwrites the value of 'iter_ret' causing us to lose the error return value and proceed as if the buffer has enough space. Fix this by returning -ERANGE directly (the path is automatically freed) instead of breaking from the while loop. Fixes: 184b3d190087 ("btrfs: use btrfs_for_each_slot in btrfs_listxattr") Assisted-by: LLM (found the bug) Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a97114b9b00ed3d05156f3b2ddbf797296260389 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 2797eb38773a96914ccedeec71eb2144645400b2 Author: Yang Xiuwei Date: Wed Aug 19 10:54:34 2026 +0800 btrfs: unlock inode and extent in caller when io_uring read extent fails [ Upstream commit b6e8add5d79d1f6f819a054c833bab452bd7365d ] btrfs_uring_read_extent() runs only after btrfs_encoded_read() has taken the inode shared lock and the extent lock. On failure it used to unlock in out_fail, and a pages-array allocation failure returned -ENOMEM without unlocking at all. Unlock in the caller instead on all failure returns, matching the copy_to_user() error path. The deferred -EIOCBQUEUED path still unlocks in btrfs_uring_read_finished(). Fixes: 34310c442e17 ("btrfs: add io_uring command for encoded reads (ENCODED_READ ioctl)") Suggested-by: Qu Wenruo Reviewed-by: Qu Wenruo Signed-off-by: Yang Xiuwei Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7a3addbdc5ad1fd80541a6a4ff4e06cd1331530a Author: Yang Xiuwei Date: Wed Aug 19 10:54:33 2026 +0800 btrfs: free iov when btrfs_uring_read_extent() fails [ Upstream commit a8ea92830b3e0e163d4e829bdcb17ca83c0f951c ] After btrfs_uring_read_extent(), the caller always jumped to out_acct. That skips kfree(data->iov), which is only correct for -EIOCBQUEUED where the deferred path owns the iov. On failure, fall through to out_free instead. Fixes: 34310c442e17 ("btrfs: add io_uring command for encoded reads (ENCODED_READ ioctl)") Signed-off-by: Yang Xiuwei Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 033dda5b321f01661de518a8d5c8607ae8675b14 Author: Yang Xiuwei Date: Wed Aug 19 10:54:32 2026 +0800 btrfs: always return -EIOCBQUEUED after btrfs_uring_read_extent_endio [ Upstream commit 80a8dbb30d2b00b9c671b02bd73f700f6d20100f ] If all bios finish before btrfs_encoded_read_regular_fill_pages() returns, it calls btrfs_uring_read_extent_endio() and previously returned the I/O status. A negative errno then made btrfs_uring_read_extent() unlock and free while btrfs_uring_read_finished() did the same again. Return -EIOCBQUEUED so only the deferred path cleans up. Reported-by: Yue Sun Closes: https://lore.kernel.org/linux-btrfs/20260630091609.3414-1-samsun1006219@gmail.com/ Suggested-by: Jens Axboe Fixes: 34310c442e17 ("btrfs: add io_uring command for encoded reads (ENCODED_READ ioctl)") Signed-off-by: Yang Xiuwei Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 77de9adf46f5b8d1e77b07676e92e78acd9eb96f Author: Shin'ichiro Kawasaki Date: Wed Sep 16 15:56:57 2026 +0900 zloop: zero out only the unread tail of short reads [ Upstream commit 58304e139cb3fa640da74bc02101f0926d0607e2 ] zloop_complete_rq() handles a short read from a zone's backing file by zero-filling every bio in the request. This is correct when the entire request is beyond the written part of the zone. When a read request straddles the boundary between written and unwritten data, read_iter() returns a partial byte count and zloop then zeroes the whole request even for the partially read area with valid data. Such an unexpected zero data read was observed with fio test script t/zbd/test-zbd-support and its test case 69, failing with "bad magic header 0". Avoid the unexpected zero data read by zeroing out only the unread tail part. When read data size cmd->ret is smaller than the request size, call the new helper function zloop_fill_zero_rq() that walks through each bio_vec and fills zeros from the specified start offset. Fixes: eb0570c7df23 ("block: new zoned loop block device driver") Reviewed-by: Damien Le Moal Reviewed-by: Christoph Hellwig Signed-off-by: Shin'ichiro Kawasaki Link: https://patch.msgid.link/20260916065657.62724-1-shinichiro.kawasaki@opensource.wdc.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7057b683922fc88ed8f936c1488fd14af2b9e262 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 ce79a6c5cc1b8054ec8d3eba16adda4a36113438 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 e76979e27f0c5065d9383ff39f63b04a26f6e5c3 Author: Guixin Liu Date: Sun Sep 20 11:34:59 2026 +0800 nvmet: return Invalid Field for invalid NSIDs feature 82h [ Upstream commit d99bc5b456fd63be46c8bda20dbf6ede93d2fc11 ] The Reservation Notification Mask feature (FID 82h) defines its own status code for namespaces that do not support reservations: "If a Set Features command or a Get Features command attempts to access the Reservation Notification Mask on a namespace that does not support reservations or is invalid, then that command is aborted with status code of Invalid Field in Command." -- NVMe Base Specification, section 5.2.26.1.33 The Set Features handler routes the namespace lookup through nvmet_req_find_ns(), which returns Invalid Namespace or Format for an unknown NSID. That is the correct status for the generic namespace-scoped admin commands, but not for this feature: a Set Features 82h naming a nonexistent NSID is aborted with Invalid Namespace or Format instead of Invalid Field in Command. Translate the lookup failure to Invalid Field in Command. The broadcast NSID, the namespace-without-reservations case and everything else keep their current behavior. Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Reviewed-by: Christoph Hellwig Reviewed-by: Nilay Shroff Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit b7725acf9c574debb97ae1613569ac9e148438be Author: Bryan Fraschetti Date: Mon Sep 28 16:04:24 2026 -0700 ice: Restore Ordered MMIO Writes for Tx Doorbells [ Upstream commit 7a579dec8423bba7bec96fcfcb2e30838b0858ee ] The DQL accounting state which tracks the number of bytes queued for the NIC to transmit, namely dql->num_queued, is updated by the ICE driver when it invokes __netdev_tx_sent_queue(). Subsequently the driver updates the hardware queue tail allowing the NIC to begin processing the work queue. The queue accounting update should be ordered before the NIC begins transmitting descriptors. The transmit path currently updates the hardware doorbell using writel_relaxed(), which (on arm64) does not provide the same ordering guarantees between writes to normal memory and writes to MMIO registers that writel() does. This introduces a potential race where the NIC begins transmitting descriptors before the dql->num_queued update is globally visible. If the NIC finishes before the update is observed by dql_completed(), it detects an invalid state where more bytes have been completed than have been queued. When this happens the following BUG_ON is triggered. BUG_ON(count > num_queued - dql->num_completed); This has been observed and manifests as the following crash (note that the trace has been trimmed) in an environment with sustained network load that uses an Intel Corporation Ethernet Controller E810-XXV for SFP (rev 02) on an arm64 machine. Replacing writel_relaxed() with writel() in a test kernel eliminated the crash in the user's workload, which previously reproduced the issue reliably. kernel BUG at lib/dynamic_queue_limits.c:99 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x268/0x2a0 lr : ice_clean_tx_irq+0x1d4/0x620 [ice] Call trace: dql_completed+0x268/0x2a0 (P) ice_napi_poll+0x94/0x520 [ice] __napi_poll+0x48/0x3f0 net_rx_action+0x194/0x420 This restores the behaviour prior to commit ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support"), which changed the notification mechanism from writel() to writel_relaxed(). Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161572 Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Bryan Fraschetti Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260928230429.495442-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cbab667ef8b5d394d7e7e733add1a1947d049c1d 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 c83bf3973da6fccee8029fc5159a2a34b150f8df 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 7110c7f70c59eb7924e79853bcc00e2a026662e6 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 181cb48c1e9af6b402567e132f879f89d1c54131 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 85e5512369d4fe6e5f2c43712d9f9e01d4ae8437 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 bea10b84e22efa22b005e8dba1a19df4e04a7649 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 742619c8637b923b2904e11811022d4accf50550 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 01318927a9055136c207399eeb36ce07becac179 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 5b26dbb27c0cb0e1b92fc0626c6ae052da8ff7d6 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 73e8503fac49c59f2447574c392bde32d79fac79 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 39ab048cce70d50af48015f5f294c4cf80d6ba89 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 62a167e7e6d8cc5fa735be38024b4775e44df72b Author: Christian Brauner Date: Wed Sep 23 14:27:59 2026 +0200 fs: don't let a migrating task hide its reference from do_umount() [ Upstream commit 7eb84d54fac5002bd975d1de8fd61d57e89172ab ] propagate_mount_busy() uses mnt_get_count() via do_refcount_check() to figure out whether a synchronous umount may proceed or not by summing the per-CPU mnt_count counter under mount_lock. The fastpath for mntget() and mntput() doesn't require that lock. A task that already holds a reference and takes another one on a cpu the loop has summed can get migrated and drops that reference again on another cpu. The loop might not have reached that cpu yet. That ends up undercounting. The original reference of the task is missed and umount() ends up succeeding with the file still open. The mount is destroyed later when the task mntput()s so it degrades to a lazy umount. That's basically the umount(2) variant of commit 9ea0a46ca2c3 ("fix mntput/mntput race") closed for the final mntput(). The same cpu-migration caused a UAF. Luckily this isn't a UAF. It's just a hidden reference pinning the mount but it's wrong nonetheless. Like the other race it's a narrow window but I can reproduce it reliably with some patching. The debug patch below prints the sum the loop computed next to an immediate re-sum of the same counters. It reports who drops the last reference to that mount later: # --- a/fs/namespace.c # +++ b/fs/namespace.c # @@ -34,6 +34,8 @@ # #include # #include # #include # +#include # +#include # # #include "pnode.h" # #include "internal.h" # @@ -263,17 +265,48 @@ # #endif # } # # +static u32 mnt_get_count_delay_ms; # +static int mnt_get_count_debug_id; # + # +static int __init mnt_get_count_debug_init(void) # +{ # + debugfs_create_u32("mnt_get_count_delay_ms", 0600, NULL, # + &mnt_get_count_delay_ms); # + return 0; # +} # +late_initcall(mnt_get_count_debug_init); # + # /* # * vfsmount lock must be held for write # */ # int mnt_get_count(struct mount *mnt) # { # #ifdef CONFIG_SMP # - int count = 0; # + static int seen[NR_CPUS]; # + bool slow = mnt_get_count_delay_ms && # + !(mnt->mnt.mnt_flags & MNT_UMOUNT); # + int count = 0, again = 0; # int cpu; # # for_each_possible_cpu(cpu) { # - count += per_cpu_ptr(mnt->mnt_pcp, cpu)->mnt_count; # + seen[cpu] = per_cpu_ptr(mnt->mnt_pcp, cpu)->mnt_count; # + count += seen[cpu]; # + if (slow) # + mdelay(mnt_get_count_delay_ms); # + } # + if (slow) { # + for_each_possible_cpu(cpu) { # + int now; # + # + now = per_cpu_ptr(mnt->mnt_pcp, cpu)->mnt_count; # + again += now; # + pr_err("mount %d: cpu%d read %d, now %d\n", # + mnt->mnt_id, cpu, seen[cpu], now); # + } # + mnt_get_count_debug_id = mnt->mnt_id; # + pr_err("mount %d: sum %d, re-sum %d, %ps\n", # + mnt->mnt_id, count, again, # + __builtin_return_address(0)); # } # # return count; # @@ -1350,6 +1383,9 @@ # smp_mb(); # mnt_add_count(mnt, -1); # count = mnt_get_count(mnt); # + if (count == 0 && mnt->mnt_id == mnt_get_count_debug_id) # + pr_err("mount %d: last put by %s (%d)\n", mnt->mnt_id, # + current->comm, task_pid_nr(current)); # if (count != 0) { # WARN_ON(count < 0); # rcu_read_unlock(); A task holds open a directory fd on a tmpfs. A synchronous rumount() of the tmpfs sums up. Concurrently a task calls fchdir() on that fd on CPU 0 and fchdir()s back to / on CPU 3. This will cause a path_get() and a path_put() with a migration in between without mount_lock held. Adding a delay per CPU makes the count loop miss the get in a cpu it already visited but count the put in one it hasn't. The reproducer, run as root with debugfs mounted: /* * gcc -static -o umount-torn umount-torn.c */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #define KNOB "/sys/kernel/debug/mnt_get_count_delay_ms" #define MNT "/mnt/x" static int kmsg; static void pin(int cpu) { cpu_set_t s; CPU_ZERO(&s); CPU_SET(cpu, &s); sched_setaffinity(0, sizeof(s), &s); } static void knob(const char *v) { int fd = open(KNOB, O_WRONLY); write(fd, v, strlen(v)); close(fd); } int main(void) { int last = sysconf(_SC_NPROCESSORS_ONLN) - 1; int p[2], fd, ret; pid_t pid; char c; kmsg = open("/dev/kmsg", O_WRONLY); mkdir(MNT, 0755); mount("none", MNT, "tmpfs", 0, NULL); fd = open(MNT "/f", O_WRONLY | O_CREAT, 0644); write(fd, "still here\n", 11); close(fd); pipe(p); pid = fork(); if (pid == 0) { int dirfd = open(MNT, O_RDONLY | O_DIRECTORY); int rootfd = open("/", O_RDONLY | O_DIRECTORY); struct stat st; char buf[16]; /* one get/put pair while the umount is summing */ usleep(150000); pin(0); fchdir(dirfd); /* mntget() */ dprintf(kmsg, "holder %d: get on cpu %d\n", getpid(), sched_getcpu()); pin(last); fchdir(rootfd); /* mntput() */ dprintf(kmsg, "holder %d: put on cpu %d\n", getpid(), sched_getcpu()); /* the umount has returned, is the fd still good? */ read(p[0], &c, 1); fd = openat(dirfd, "f", O_RDONLY); ret = read(fd, buf, sizeof(buf)); dprintf(kmsg, "holder %d: fstat %d openat %d read %d\n", getpid(), fstat(dirfd, &st), fd, ret); _exit(0); } pin(1); knob("100"); ret = umount2(MNT, 0); knob("0"); if (ret) dprintf(kmsg, "umount: %s\n", strerror(errno)); else dprintf(kmsg, "umount: 0\n"); write(p[1], "x", 1); waitpid(pid, NULL, 0); return 0; } The log shows the busy check summing 2 and when read right after it reads 3. The loop read CPU 0 before the get landed there and CPU 3 after the put did. The umount succeeds while there's still someone with an fd. The mount is then dropped when the fd goes: [ 2.511944] holder 90: get on cpu 0 [ 2.512023] holder 90: put on cpu 3 [ 2.671388] mount 28: cpu0 read 1, now 2 [ 2.671398] mount 28: cpu1 read 2, now 2 [ 2.671401] mount 28: cpu2 read 0, now 0 [ 2.671404] mount 28: cpu3 read -1, now -1 [ 2.671407] mount 28: sum 2, re-sum 3, propagate_mount_busy [ 2.671773] umount: 0 [ 2.672963] holder 90: fstat 0 openat 8 read 11 [ 2.673663] mount 28: last put by umount-torn (90) Easy fix would be to order mntget() against the loop that sums up. But that's a full barrier and a flag test in mntget() afaict. No bueno... That would cost every path_get(). So learn from SRCU. Keep gets and puts in separate per-cpu counters and make mnt_get_count() sum all puts first and all gets second with a full barrier in between. A put is always after its own get (hopefully...) independent of the cpu the task is on. So a put the first pass counted must have its get visible to the second pass. Ergo, we can't undercount. This is the two pass sum srcu_readers_active_idx_check() does for srcu_locks and srcu_unlocks. mntget() keeps a single this_cpu_inc(). mntput() gains an smp_wmb() before its increment, a compiler barrier on x86 and a store fence on the weakly ordered architectures, since the two counters are two words and a put stored after a get could otherwise become visible before it. The counters are unsigned so the difference stays right after they wrap. The count can still come out high when a get is counted whose put the first pass did not see. We don't care. A task can only take a new reference if: (1) it holds one already (2) through __legitimize_mnt() which the seqcount orders against the write side So a get in this window means someone has a reference and -EBUSY is correct. The final mntput() is unchanged. Once ->mnt_ns is NULL every put takes the slow path under mount_lock and so no put is in flight while it counts. Here's an attempted proof for that crap: (i) A put never becomes visible before its get. Within one task the smp_wmb() in mntput_no_expire() orders every earlier store before the increment of the puts. Any task that migrated in between had its stores flushed by the scheduler. When that reference is handed to another task that's trivially true. (ii) The double count in mnt_get_count() is ordered via smp_mb(). That keeps every read of the puts counter before every read of the gets counter. (iii) We never undercount by (ii). (iv) There are no spurious counts/differences. A get is counted only if it happened and a put is left out only if it hasn't happened when the counter was read. With (iii) this means it's equivalent to the old count whenever nothing is taken or dropped during the loop. (v) do_umount() holds a reference and mount_lock hence. New references come from: (v.a) __legitimize_mnt() managed by the seqcount. Either it's smp_mb() made the get visible to the loop or it takes the lock and waits for the loop. By (iii) a mount with a additional references is refused. By (iv) refusing the umount just means that any additional reference existed, same as the old counter. (vi) mntput_no_expire_slowpath() runs with ->mnt_ns already NULL. Hence, every other put must take the slowpath as well and hangs on mount_lock. The grace period in namespace_unlock() will make every fast path do a put that still saw ->mnt_ns. No put is in flight during the loop. A get that is in flight comes from a task holding another reference. That must be included by the count or from __legitimize_mnt() as in (v). Ergo, zero means the last reference and non-zero means a reference is live. (vii) may_umount() uses propagate_mount_busy() as well and may_umount_tree() sums mnt_get_count() itself. With this patch the race is dead: [ 3.066786] mount 28: sum 3, re-sum 3, propagate_mount_busy [ 3.105867] umount: Device or resource busy [ 3.106047] holder 90: fstat 0 openat 8 read 11 Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-7-f424cf8d3242@kernel.org Fixes: b3e19d924b6e ("fs: scale mntget/mntput") Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 6850385e26bf280aed382179815b0f505ac34af4 Author: Mateusz Guzik Date: Fri Nov 14 21:18:03 2025 +0100 fs: move mntput_no_expire() slowpath into a dedicated routine [ Upstream commit bfef6e1f3488fc09ae966cb4dd2cb09f73cff791 ] In the stock variant the compiler spills several registers on the stack and employs stack smashing protection, adding even more code + a branch on exit.. The actual fast path is small enough that the compiler inlines it for all callers -- the symbol is no longer emitted. Forcing noinline on it just for code-measurement purposes shows the fast path dropping from 111 to 39 bytes. Signed-off-by: Mateusz Guzik Link: https://patch.msgid.link/20251114201803.2183505-1-mjguzik@gmail.com Signed-off-by: Christian Brauner Stable-dep-of: 7eb84d54fac5 ("fs: don't let a migrating task hide its reference from do_umount()") Signed-off-by: Sasha Levin commit 7505f139d8995b8b0f1dbfd37461e52090ea289c Author: Christian Brauner Date: Wed Sep 23 14:27:55 2026 +0200 mount: refuse MOVE_MOUNT_SET_GROUP on an unbindable mount [ Upstream commit a2b42babc912e4fb428cbb42adb4f6e1e067113d ] do_set_group() only accepts mounts as targets that are neither shared nor a slave. That encompasses undindable mounts. If the source mount is a slave mount the target mount will end up with source's master as its master. It keeps T_UNBINDABLE. That means we get a mount that is both unbindable and a slave: mount --bind /tmp/src /tmp/src mount --make-shared /tmp/src mount --bind /tmp/src /tmp/b mount --make-slave /tmp/b mount --bind /tmp/src /tmp/c mount --make-unbindable /tmp/c move_mount(b, "", c, "", MOVE_MOUNT_SET_GROUP) grep /tmp/c /proc/self/mountinfo ... /tmp/c ... master:646 unbindable ... This property cannot be produced any other way. change_mnt_propagation() drops the master when it makes a mount unbindable (iow, it becomes private) and doesn't touch an unbindable mount when it is supposed to turned into a slave mount. End-result is that the unbindable-slave mount receives everything propagated from its master's peer group while it can't be bind mounted itself. Not sure what that's supposed to do. On the other side: if the source mount is shared, the target mount drops T_UNBINDABLE because because set_mnt_shared() clears T_SHARED_MASK. So teach do_set_group() to refuse an unbindable target mount the same way a shared or slave target mount is refused. The main user of MOVE_MOUNT_SET_GROUP is CRIU which restores sharing first and applies MS_UNBINDABLE afterwards. It never hits this. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-3-f424cf8d3242@kernel.org Fixes: 9ffb14ef61ba ("move_mount: allow to add a mount into an existing group") Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit cc21cda4cac5da22d890091f79200b324c9c0233 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 5a673697e4a3efd17d58328b280bd0e3b91b3346 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 ab0f32981ce395d80672af5f0def5b68b829f992 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 fea9c705bbc618ba6426424c9f8330555820c9ec Author: Ze Tan Date: Fri Aug 14 10:36:29 2026 +0800 smb/server: fix tree connection leak in smb2_tree_connect() [ Upstream commit 39f2032096715daae5f6fd0f587ca7a474b019df ] See the procedure below: smb2_tree_connect ksmbd_tree_conn_connect xa_store(&sess->tree_conns, tree_conn->id, tree_conn) ksmbd_counter_inc(KSMBD_COUNTER_TREE_CONNS) ksmbd_share_tree_conn_inc(sc) ksmbd_iov_pin_rsp // fail status.ret = KSMBD_TREE_CONN_STATUS_NOMEM // do not disconnect tree_conn Disconnect the new tree connection if ksmbd_iov_pin_rsp() fails. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 46a431c0a25a878bdd3392dba6632a15a4685682 Author: Namjae Jeon Date: Mon Feb 9 21:33:44 2026 +0900 ksmbd: convert tree_conns_lock to rw_semaphore [ Upstream commit 31b9028c77dc279d720412013e95b279b1385aed ] Converts tree_conns_lock to an rw_semaphore to allow sleeping while the lock is held. Additionally, it simplifies the locking logic in ksmbd_tree_conn_session_logoff() and introduces __ksmbd_tree_conn_disconnect() to avoid redundant locking. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 39f203209671 ("smb/server: fix tree connection leak in smb2_tree_connect()") Signed-off-by: Sasha Levin commit 0af43b52fe4b1751b731c067127fdf47cf1b700c Author: Tetsuo Handa Date: Tue Aug 4 22:52:19 2026 +0900 printk: Don't WARN on kthread_run failure. [ Upstream commit 72dd0ec09e7cc98ed58ddeac26575e5d1ab8a93d ] Since __kthread_create_on_node() returns -EINTR upon SIGKILL, we should not use WARN_ON() in order to catch kthread_run() failure. Reported-by: syzbot+1ebbc20f223b99446034@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1ebbc20f223b99446034 Fixes: 5f53ca3ff83b ("printk: Implement legacy printer kthread for PREEMPT_RT") Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: Tetsuo Handa Reviewed-by: John Ogness Reviewed-by: Petr Mladek Link: https://patch.msgid.link/76bb4c1c-5d85-4635-b3bb-fc06f292c59e@I-love.SAKURA.ne.jp Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 9bf96b4347f541604b3caadeabda0773d9ceaf2a Author: Eduard Zingerman Date: Wed Aug 26 11:18:44 2026 -0700 bpf: check_cond_jmp_op(): properly infer if register is null [ Upstream commit d3ef6c097ba078e1f8c7239d76a0ce8b61e75095 ] Nicholas Carlini reported a bug when verifier can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when processing comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived based on the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit the behavioural change from this commit. Fixes: befae75856ab ("bpf: propagate nullness information for reg to reg comparisons") Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260826-bug-029-bad-non-null-inference-v2-1-136789ace9e9@localhost Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8a3257f142ae513d0c96d42f97386d4941bcec29 Author: Lorenzo Bianconi Date: Wed Aug 26 15:03:15 2026 +0200 net: stmmac: fix dma mapping leak in stmmac_tso_xmit() [ Upstream commit a5d946466a95621fa2769720d59ea336003aa1a5 ] In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the frame is dropped but the DMA mappings already created for the linear part and for the fragments mapped before the failure are never unmapped, leaking DMA mappings. Fix the leak by walking back over the descriptors used by the frame and releasing each of them with stmmac_free_tx_buffer(). Moreover, release the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers. Fixes: f748be531d70 ("stmmac: support new GMAC4") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260826-stmmac_dma_unmap_tso-v1-1-a2753d1576ba@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit afca229b39acc2590976b3e4f6e0fe76cededc60 Author: Eric Dumazet Date: Fri Aug 28 08:45:30 2026 +0000 ipv6: mcast: use rcu_assign_pointer() for __rcu list updates [ Upstream commit 0c8f56c583c3250408367880c98e4d6fbc929315 ] Several places in net/ipv6/mcast.c update RCU-protected lists (np->ipv6_mc_list, idev->mc_list, idev->mc_tomb) using direct pointer assignments instead of rcu_assign_pointer(): 1. In __ipv6_dev_mc_dec(), unlinking a group from idev->mc_list did: *map = ma->next; without rcu_assign_pointer() while concurrent readers traverse idev->mc_list locklessly under rcu_read_lock(). 2. In ipv6_sock_mc_drop() and __ipv6_sock_mc_close(), unlinking a group from np->ipv6_mc_list directly assigned *lnk = mc_lst->next and np->ipv6_mc_list = mc_lst->next without rcu_assign_pointer(), racing with lockless readers in inet6_mc_check(). 3. In __ipv6_sock_mc_join(), mc_lst->next was initialized to np->ipv6_mc_list via raw assignment before publishing mc_lst. 4. In mld_del_delrec() and __ipv6_dev_mc_inc(), __rcu source pointers passed into rcu_assign_pointer() lacked explicit dereference helpers. Fix these by consistently using rcu_assign_pointer() along with mc_dereference() / sock_dereference(). Fixes: 456b61bca8ee ("ipv6: mcast: RCU conversion") Fixes: 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45462e5ba345a0305644785aeb64949a26d8be66 Author: Yuyang Huang Date: Sun May 24 11:24:56 2026 +0900 ipv6: mcast: annotate data-races around mca_users [ Upstream commit 56ed77ff6022271e172f043b44193889226e42b0 ] /proc/net/igmp6 walks IPv6 multicast memberships under RCU and prints mca_users without holding idev->mc_lock, while multicast join and leave paths update the field while holding idev->mc_lock. Annotate this intentional lockless snapshot with READ_ONCE() and the matching writers with WRITE_ONCE(). Signed-off-by: Yuyang Huang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260524022456.20689-1-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0c8f56c583c3 ("ipv6: mcast: use rcu_assign_pointer() for __rcu list updates") Signed-off-by: Sasha Levin commit a0cd9e22f8faed30a8da8be357c51bd8b3074ee9 Author: Eduard Zingerman Date: Wed Sep 2 00:28:34 2026 -0700 bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge [ Upstream commit 387b1baefbb776e3f48dc2261e77a49213f470f7 ] Nicholas Carlini reported a bug in precision backtracking mechanism for BPF_LD | BPF_{IND,ABS} instructions. These instructions are modelled as two branches: - fallthrough; - implicit exit from current subprogram. The implicit exit case was not handled by the backtrack_insn() function. When backtracking such a path backtrack_insn() did not call bt_subprog_enter(), which meant that backtracking continued manipulating precision marks in a caller frame, while looking at instructions in a callee frame. This lead to segmentation faults during verification (see the selftest), or unsound state pruning. Fixes: ee861486e377 ("bpf: Fix ld_{abs,ind} failure path analysis in subprogs") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260901-bug-016-backtrack-ld-abs-v1-1-59368f1be435@gmail.com Signed-off-by: Sasha Levin commit 3a39bc9707fbd1bef4df7318a9d02222741dda5b Author: Eduard Zingerman Date: Mon Aug 31 18:36:09 2026 -0700 bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks [ Upstream commit e3e4f66cc4b72333d0886ae2673c360248987889 ] When processing calls to bpf_loop() verifier marks R1 (and R4) as precise. R1 tracks loop iterations number and because of the 'callback_depth < R1' mechanics in check_helper_call() must be marked precise. However, precision propagation for R1 was broken, when bpf_loop() call was verified on a second iteration. Consider the following verification trace: - main: bpf_loop(nr_loops, callback ...) - callback: BPF_EXIT - main: bpf_loop(nr_loops, callback ...) - ... While the first visit of the call to bpf_loop() propagated R1 precision as expected, the second call to mark_chain_precision() in the check_helper_call() set R1, but it was immediately reset when backtrack_insn() processed preceding BPF_EXIT in the loop deleted in this patch. Because of that, the second visit of the call to bpf_loop() injected checkpoint with R1 not marked as precise. Which could trick the verifier into accepting unsafe programs. See the next patch for an example of such program. Commit is structured in a way to minimize conflicts when 'bpf' would be eventually merged with 'bpf-next'. Fixes: ab5cfac139ab ("bpf: verify callbacks as if they are called unknown number of times") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260831-bug-015-backtrack-cb-args-precise-v1-1-68a8e2a821e0@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 65f636322ac402add6046c68e9ece77b9ffd71c9 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:27 2026 +0200 bpf: Mark syscall helpers as sleepable [ Upstream commit d05524794240b52fdc3b6c1220dd05505715824d ] bpf_sys_bpf() executes the bpf(2) syscall body, which can take mutexes, allocate with GFP_KERNEL, and wait for an RCU grace period. bpf_sys_close() reaches close_fd() and filp_close(), which can sleep as well. Both helpers are limited to BPF_PROG_TYPE_SYSCALL, whose main program is sleepable. That does not make every callback sleepable: a syscall program can register a bpf_timer callback, and the verifier checks that callback in a non-sleepable context while retaining the syscall helper set. Without .might_sleep on the prototypes, such a callback can invoke bpf_sys_bpf() from hrtimer softirq context and trigger a scheduling-while-atomic failure. bpf_sys_close() is exposed through the same missing context check. Set .might_sleep on both prototypes so the existing helper-context check rejects them from timer callbacks and other atomic regions. Calls from the sleepable main body remain valid. Fixes: 79a7f8bdb159 ("bpf: Introduce bpf_sys_bpf() helper and program type.") Fixes: 3abea089246f ("bpf: Add bpf_sys_close() helper.") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-10-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 364a31052aa9ef91db137f82d797366007cd85b7 Author: Steven Rostedt Date: Thu Sep 3 13:27:28 2026 -0400 ring-buffer: Add checking nr_subbufs to persistent ring buffer validation [ Upstream commit 6c001a62c34f13fe1c6a24304c289b387d9e697d ] Sashiko reported that the code was using meta->nr_subbufs without making sure that it matched the nr_pages + 1 on data that was assuming the two were the same. Add a check to the persistent ring buffer validation code to make sure that the saved nr_subbufs matches what we expect. Link: https://patch.msgid.link/20260903132728.7fb27d34@gandalf.local.home Fixes: f5b95f1fa2ef3 ("ring-buffer: Validate the persistent meta data subbuf array") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260901164836.D962D1F000E9@smtp.kernel.org/ Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 5b40198a0c69e21db151287e161ac2a9015d9ec6 Author: Masami Hiramatsu (Google) Date: Fri May 22 13:08:58 2026 -0400 ring-buffer: Skip invalid sub-buffers when validating persistent ring buffer [ Upstream commit eb3bd277b37cd435d26a44a40d8f7c87ff16feb6 ] Skip invalid sub-buffers when validating the persistent ring buffer instead of discarding the entire ring buffer. Only skipped buffers are invalidated (cleared). If the cache data in memory fails to be synchronized during a reboot, the persistent ring buffer may become partially corrupted, but other sub-buffers may still contain readable event data. Only discard the subbuffers that are found to be corrupted. Link: https://lore.kernel.org/all/20260520185018.051228084@kernel.org/ Link: https://patch.msgid.link/20260522171050.914418536@kernel.org Signed-off-by: Masami Hiramatsu (Google) [SDR: Fixed max_loops in rb_iter_peek() as well ] Signed-off-by: Steven Rostedt Stable-dep-of: 6c001a62c34f ("ring-buffer: Add checking nr_subbufs to persistent ring buffer validation") Signed-off-by: Sasha Levin commit 6bb6ae5ab1beffda51dabf41612f501d07f10fc6 Author: Eduard Zingerman Date: Thu Sep 3 10:15:39 2026 -0700 bpf: zero extend the result of an arena 32-bit cmpxchg [ Upstream commit 4814ed6406f3493bd554ad046da5f7fc04833571 ] bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, and it runs before bpf_opt_subreg_zext_lo32_rnd_hi32(). That pass emits an explicit zero extension for a 32-bit cmpxchg even when bpf_jit_needs_zext() is false. This is done because on some architectures 32-bit cmpxchg requires explicit zero extension for the dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax if comparison is successful, while BPF semantics declare that each operation on a 32-bit register zero extends it's upper half. is_cmpxchg_insn() matches BPF_MODE == BPF_ATOMIC only, so an arena cmpxchg misses said zero extension adjustment. This patch adjusts is_cmpxchg_insn() to match BPF_PROBE_ATOMIC alongside BPF_ATOMIC. Fixes: d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903171542.1438050-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c4d3bdb3ab211dcfad734b02e06fcb12adb4757f Author: Eduard Zingerman Date: Thu Sep 3 13:58:19 2026 -0700 bpf: don't rewrite bpf_fastcall patterns entered by a jump [ Upstream commit 0b1c83dc3c4401cd7e846548f62e3caf3d06742e ] mark_fastcall_pattern_for_call() must ensure that matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is not sound. Record the instructions targeted by jumps in insn_aux_data[*].jump_target when the CFG is built and use this flag to stop growing a pattern at such an instruction. Jumps to the first spill are fine. Note that existing insn_aux_data[*].jmp_point field can't be reused, as it marks subprogram return instructions. Fixes: 5b5f51bff1b6 ("bpf: no_caller_saved_registers attribute for helper calls") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903205820.1743087-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 65bea674f43c09c0eda033a140dfac6a2842a19f Author: Eduard Zingerman Date: Fri Sep 4 01:33:18 2026 -0700 bpf: Don't infer non-NULL from a pointer with an unbounded offset [ Upstream commit 67b529f521a6676cdfc78b91b0217d7eaa84216b ] reg_not_null() decides that a register holds a non-NULL value by looking at its type alone. For pointer types that allow arithmetic the type only guarantees a non-NULL base, in case of an unbound offset the runtime offset value might still add up to NULL. Consider the followng program: r6 = bpf_map_lookup_elem(map, &0); /* present */ if (r6 == 0) return 0; r7 = bpf_map_lookup_elem(map, &1); /* absent, NULL at runtime */ r8 = r7; r8 -= r6; /* pointer - pointer: unknown scalar, -r6 */ r8 <<= 1; r8 >>= 1; /* any non-negative offset is accepted by */ /* check_reg_sane_offset_ptr() */ r6 += r8; /* verifier: map value; runtime: zero */ if (r7 != r6) return 0; *(u8 *)(r7 + 0); /* r7 is inferred non-NULL, both are zero */ At runtime both registers are zero, the comparison is true and the load faults with NULL pointer dereference. Require the offset to be within +-BPF_MAX_VAR_OFF in reg_not_null(). Fixes: cac616db39c2 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ") Reported-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-1-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 8d19e2cdfba9ba8c8eb6a459cd666bec00a1d2c6 Author: Ning Ding Date: Fri Sep 4 10:43:16 2026 +0200 bpf: Keep refcount_acquire nullable for borrowed RCU kptrs [ Upstream commit dc36739e5cc9f60485418a910b42bc95339218d2 ] bpf_refcount_acquire() is fallible for a borrowed reference because the object may have reached a zero refcount. The verifier therefore keeps KF_RET_NULL on the return value unless the argument is an owning reference. An RCU-protected load of a local kptr is marked MEM_ALLOC, but it only receives NON_OWN_REF when the pointee contains a graph node. A refcounted object without a graph node consequently looks like an owning reference even though the loaded register has no acquired reference state. If the program drops the last real reference while remaining in the RCU critical section, refcount_inc_not_zero() returns NULL while the verifier treats the result as non-NULL. Only classify the argument as owning when it is backed by a verifier-tracked reference. This retains the non-NULL return for pointers from bpf_obj_new(), bpf_kptr_xchg(), or an earlier successful acquisition, while requiring a NULL check for borrowed RCU kptrs. Fixes: 1b12171533a9 ("bpf: Mark direct ld of stashed bpf_{rb,list}_node as non-owning ref") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Ning Ding [ kkd: Rewrote commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bb667eb575c906f24c707986541a99424c5b07ea Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:56 2026 +0200 bpf: Mark NULL kptr stores precise [ Upstream commit ecdc5043794c9184aa8e6c814603899479c46b35 ] check_map_kptr_access() permits a scalar store into an untrusted kptr field only when the register is known to contain zero. Unlike other verifier checks whose outcome depends on a scalar value, it does not mark that register precise. A state checkpoint reached with an imprecise zero can therefore prune a second path that reaches the store with an arbitrary nonzero scalar. The program can write attacker-controlled bits into the kptr field and load them back as a PTR_TO_BTF_ID. Call mark_chain_precision() before accepting a known-zero register. This forces state equivalence to compare its scalar range and makes the verifier visit and reject a path carrying a nonzero value. Fixes: 61df10c7799e ("bpf: Allow storing unreferenced kptr in map") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904104203.345917-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 08b534bafdd9de65b6374474a8fe719c90eb3b01 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:58 2026 +0200 bpf: Preserve inner map identity in callback frames [ Upstream commit b90c5d770dad910fb89e6c1b15052a8a1e8db752 ] Callback frame constructors initialize map-typed argument registers with __mark_reg_known_zero() and then restore map_ptr. This clears map_uid, which is the only field distinguishing inner maps that share an inner_map_meta template. When a timer callback invokes bpf_for_each_map_elem() on a second inner map, both the saved first map and the second map value can reach the nested callback as the same template with map_uid zero. bpf_timer_init() then accepts pairing the timer from the second map with the first map. The runtime records the first map in the timer without taking a reference. Freeing that map does not find the timer stored in the second map, so a later timer callback dereferences the freed map. Copy map_uid from the same caller register as map_ptr when constructing for-each, timer/workqueue, and task-work callback arguments. The existing identity check can then reject mismatched inner maps while allowing a callback value to be paired with its actual map. Fixes: 3e8ce29850f1 ("bpf: Prevent pointer mismatch in bpf_timer_init.") Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Fixes: 5c8fd7e2b5b0 ("bpf: bpf task work plumbing") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3f30b2cd4eba45c05f822f03f1b0f4077d6d4dc3 Author: Vincent Donnefort Date: Fri Sep 4 17:44:48 2026 +0100 tracing: Fix subbuf resize races with trace_pipe_raw readers [ Upstream commit dae8dda341d2d9034a90d59e8a7d502e1263813f ] Concurrent subbuffer resizes may crash trace_pipe_raw readers or leak uninitialized memory to userspace due to stale size values. Modify ring_buffer_alloc_read_page() to handle the resizing of an existing buffer_data_read_page if necessary and add a new ring_buffer_read_page_size(). This new function enables ring-buffer buffer_data_read_page users to not call the racy ring_buffer_subbuf_size_get(). This makes the spare_size member of ftrace_buffer_info redundant. Finally, handle buffer_data_read_page/reader_page order discrepancy in ring_buffer_read_page(). On a mismatch simply copy manually the data to the buffer_data_read_page. Link: https://lore.kernel.org/all/20260817140812.2C7D41F00A3A@smtp.kernel.org/ Link: https://patch.msgid.link/20260904164450.1345852-3-vdonnefort@google.com Fixes: bce761d75745 ("ring-buffer: Read and write to ring buffers with custom sub buffer size") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit b1fe6379e401b8ce0f561cb4d84af2b70b4343c3 Author: Eduard Zingerman Date: Fri Sep 4 17:05:52 2026 -0700 bpf: mark a NULL call argument precise [ Upstream commit 1a3a10b030c96ea88868ccc060a16827c01eaa5a ] check_func_arg() allows bpf_register_is_null() for nullable arguments w/o marking the underlying scalar register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value. check_helper_call() enforces second parameter of the bpf_get_local_storage() to be zero, w/o marking the underlying scalar register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value. Grouping these two into one patch, as they share the same fixes tag. Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-1-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 787405e9e7bdc53ea7e063fe7b855171b4bd0e91 Author: Fangyu Yu Date: Tue Sep 1 21:39:19 2026 +0800 iommu/riscv: Serialize command queue publishing [ Upstream commit ca58afa40946acd252a50fa4d4a86f15847a3d7d ] Serialize command queue publishing so software producer state advances only after a command is written and the hardware tail is updated. Wait for hardware consumption outside the queue lock when the command queue is full so other CPUs are not blocked behind a long poll. Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3e6400e3b8b858cdf0f8d70b20d8b55d703af368 Author: Alexander Graf Date: Mon Aug 17 22:32:29 2026 +0000 virtio_ring: fix stale descriptor flags after a failed packed add [ Upstream commit 75d276e5bb68778b2916f98a2bc30f142ebadc64 ] In a packed ring the AVAIL and USED bits sit in the descriptor itself, so writing them makes that descriptor available. Those bit combinations flip meaning on every round of the ring, tracked by a wrap counter, so invalidating or validating a descriptor means inverting both bits. Commit 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") has virtqueue_add_packed() make every descriptor of a chain available as it maps the chain, and write the head last. The device consumes the ring in order and stops at a head that is not available yet, so it never reaches the rest. When vring_map_one_sg() fails partway, unmap_release unmaps the segments and restores avail_used_flags, but the descriptors it wrote to in the ring stay marked with AVAIL and USED bits. The head is now the only entry that keeps the device from consuming these stale entries. For example, the ring would look like this now. Z - pre-previous command A - previous command B - aborted command C - current command [A1 DONE] [A2 DONE] [B2] [B3] [Z1 DONE] When the driver now attempts to issue the C command, the next add starts at the same head as B. If C spans less descriptors than B, there is no end marker because AVAIL and USED bits were still in place. And that means the device will start interpreting these stale entries (B2/B3) as another command entry, which then blocks the queue. This effect typically happens in swiotlb configurations under memory pressure, because vring_map_one_sg() can then fail with larger I/O requests which then leads to command abortions. There are broadly 2 ways to avoid leaving those flags behind: 1) Defer those flags too until the chain is complete. 2) Rewrite those flags for the previous wrap counter. Implement the second option in both packed add paths. The first option traverses the chain a second time on every successful add. The second option invalidates all added descriptors when any add fails. With this patch applied, a packed virtqueue keeps completing requests after a failed add. Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") Fixes: f6a15d854986 ("virtio_ring: add in order support") Assisted-by: Kiro:claude-opus-5 checkpatch sparse Signed-off-by: Alexander Graf Signed-off-by: Michael S. Tsirkin Message-ID: <20260817223229.28954-1-graf@amazon.com> Signed-off-by: Sasha Levin commit 831dab9b9bcc184adf78f18b5b788316e3174aec Author: Jia Jia Date: Sun Aug 30 10:33:54 2026 +0800 vduse: validate virtqueue alignment [ Upstream commit fa2c25b4add57888acfa89e398389e267bff3dcf ] vduse_validate_config() only checks the upper bound of vq_align. Invalid values can therefore reach vring_create_virtqueue_map(). The split-ring helpers use align - 1 as a bit mask, so the alignment must be a non-zero power of two. A zero value makes vring_size() drop the descriptor and available-ring part and vring_init() leave the used ring pointer NULL. The VIRTIO spec requires the used ring to start at an address aligned to at least 4 bytes. Reject values below VRING_USED_ALIGN_SIZE as well as non-power-of-two values before they reach the virtio ring helpers. Opening a virtio-net device created with vq_align=0 triggered: BUG: KASAN: null-ptr-deref in virtqueue_kick_prepare_split+0xe3/0x100 Read of size 2 at addr 0000000000000000 by task systemd-network/1062 Call Trace (relevant frames): dump_stack_lvl print_report kasan_report __asan_load2 virtqueue_kick_prepare_split+0xe3/0x100 virtqueue_kick_prepare+0x40/0x60 try_fill_recv+0x857/0x1250 virtnet_open+0x189/0x460 __dev_open+0x225/0x390 __dev_change_flags+0x368/0x3b0 netif_change_flags+0x56/0xc0 do_setlink.isra.0+0x68c/0x1e30 Validate the value before it reaches the virtio ring helpers. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260830023354.115333-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit 7f8ee0b8f632441aec456a7c147fb43f5c73542d Author: Jia Jia Date: Fri Aug 28 16:57:21 2026 +0800 vhost: invalidate vring access on IOTLB transitions [ Upstream commit e4f4761879a230aa59e569102a6ab9851847d833 ] When VIRTIO_F_ACCESS_PLATFORM changes, cached vring pointers and IOTLB metadata are interpreted in a different address space. Keeping them across the transition can leave stale ring mappings in use. Clearing d->iotlb before taking the VQ locks also lets a worker observe a transient NULL d->iotlb and fall back to d->umem while translating a descriptor. Add a common vhost_clear_device_iotlb() helper for vhost-net and vhost-vsock. Take all VQ mutexes in index order before dropping the device-wide IOTLB, invalidate each VQ's cached ring access and metadata, clear pending IOTLB messages, and free the old table after the handoff. This serializes the transition with workers and prevents mixed address space mappings. On the first direct-to-IOTLB transition, invalidate the cached vring addresses. When an existing device IOTLB is replaced, preserve the GIOVA ring addresses and reset only the metadata cache. After clearing ACCESS_PLATFORM, userspace must configure the vring addresses for the new address mode. vhost_vq_invalidate_access() clears desc, avail, and used together. Treat the VQ as invalidated only when all three are NULL, since a single GIOVA address may legitimately be zero. Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API") Fixes: e13a6915a03f ("vhost/vsock: add IOTLB API support") Suggested-by: Michael S. Tsirkin Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260828085721.57816-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit d9232a90c6f7de822177d35d73d9234cba523ef9 Author: Steven Rostedt Date: Thu Sep 10 22:12:09 2026 -0400 tracing: Take trace_array reference when opening a tracer options file [ Upstream commit ed0aff60f83a9bdc2f6556376ac79c96b3ce7e80 ] When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened. Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed. To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased. Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910221209.62dad8d3@robin Fixes: 7e2cfbd2d3c86 ("tracing: Have option files inc the trace array ref count") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260902121918.5a9e9d1b@gandalf.local.home/ Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 30dacb56f07283a1acb353ce81baef31f85396b0 Author: Arunpravin Paneer Selvam Date: Wed Sep 2 18:33:48 2026 +0530 drm/amdgpu: skip the VMID 0 flush for VRAM [ Upstream commit 87ceb8cba73d0b3c4025ff42495bccd8164acaed ] Clear-on-release only runs on VRAM, which amdgpu_ttm_map_buffer() reaches via its direct MC address without programming a GART window, yet the wipe still forces a VMID 0 flush. On GFX11 (e.g. Navi33) that spurious SDMA flush can wedge the engine; only flush when a GART window is actually used. v2: Let amdgpu_ttm_map_buffer() return whether the VMID 0 flush is needed, and drive the clear and copy paths from that. (Christian) v3: Make the vm_needs_flush output parameter mandatory instead of allowing NULL. (Christian) Fixes: a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5413 Cc: Christian König Signed-off-by: Arunpravin Paneer Selvam Reviewed-by: Christian König Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit a306e406e570b74318ff7d80e5b07b540ca1d3a9) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 6ac7a29691558bed18e2df1780636b8aa0fd13d5 Author: Paulo Alcantara Date: Sun Sep 6 14:40:04 2026 -0300 smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid [ Upstream commit 18a72975e9f35aadecc75b031f693f2d1f49308f ] When the administrator mounts with forceuid or forcegid (uid=/gid= mount options), they expect all files to appear owned by the specified user/group. However, several code paths unconditionally called sid_to_id() to overwrite cf_uid/cf_gid with server-provided values, ignoring the administrator's explicit override: - smb311_posix_info_to_fattr() (stat via POSIX extensions) - cifs_posix_to_fattr() (readdir via POSIX extensions) - parse_sec_desc() (CIFS ACL ownership mapping) This allowed an untrusted server to dictate local file ownership even when the mount was configured to force specific uid/gid values. Fix all three call sites to check CIFS_MOUNT_OVERR_UID and CIFS_MOUNT_OVERR_GID before calling sid_to_id(), following the same pattern already used by cifs_unix_basic_to_fattr() for unix extensions. Closes: https://sashiko.dev/#/patchset/20260906155816.603278-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2be31f252ade791b84f7164991f14436aed1d4b9 Author: Paulo Alcantara Date: Sun Sep 6 14:40:39 2026 -0300 smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr() [ Upstream commit da6e25842431982d5a53cf00d925b98c690f4467 ] cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server), posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes them to request_key() to construct a SID string, potentially leaking kernel stack contents to the userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info' pointer so they are unaffected. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org Closes: https://sashiko.dev/#/patchset/20260906181540.647469-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 28289d880e6d11ae7ac77b81af3312453febf939 Author: Namjae Jeon Date: Sun Jul 5 09:34:03 2026 +0900 ksmbd: fix maximum allowed access checks [ Upstream commit cc2f133e80eb2c4a04bfa77a2f207749fe2f516a ] The DACL permission check looks for an ACE matching the current user and falls back to the Everyone ACE. It does not consider an Authenticated Users ACE, even though an authenticated session is a member of that well-known group. As a result, opening a file whose access is granted through S-1-5-11 can incorrectly fail with STATUS_ACCESS_DENIED. Treat an Authenticated Users ACE as a fallback entry alongside Everyone. The maximal access calculation also combines access masks from every ACE, regardless of whether its SID applies to the current user. This can grant rights belonging to an unrelated principal. Process only ACEs applying to the user, Everyone, or Authenticated Users, and accumulate allowed and denied masks in ACL order. Preserve explicitly requested access bits so they are validated against the resulting maximal mask. When ACCESS_SYSTEM_SECURITY is denied, report STATUS_PRIVILEGE_NOT_HELD instead of the generic STATUS_ACCESS_DENIED. Access to the system ACL requires a security privilege that ksmbd does not grant. For regular files, include FILE_EXECUTE in maximal access when the client requested GENERIC_EXECUTE and the DACL grants the complete file-read set. Keep a direct FILE_EXECUTE request subject to the explicit DACL bit. This matches the POSIX file ACL mapping without broadening specific execute requests. Do not replace rights from an applicable NT ACE with a POSIX ACL entry. The POSIX ACL is only a fallback when no user, Everyone, or Authenticated Users ACE applies; otherwise it can incorrectly broaden the stored DACL. This fixes smb2.maximum_allowed.maximum_allowed. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit eb2e3bb27e78cabad8077edc763ac95f6fa9bf7d Author: Alexey Velichayshiy Date: Wed Dec 10 16:51:33 2025 +0300 ksmbd: remove redundant DACL check in smb_check_perm_dacl [ Upstream commit 8dd2e58b62731a96e276ee0545fb910ffb2057d9 ] A zero value of pdacl->num_aces is already handled at the start of smb_check_perm_dacl() so the second check is useless. Drop the unreachable code block, no functional impact intended. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Velichayshiy Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cc2f133e80eb ("ksmbd: fix maximum allowed access checks") Signed-off-by: Sasha Levin commit 2e7e39bb81913feaac463b7add46bafdca06fbde Author: Val Packett Date: Sun Feb 1 17:55:03 2026 -0300 remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3 [ Upstream commit 3dbc90b9c22ea96e37bf55f6011e63b5123ec668 ] The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs. This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators. Signed-off-by: Val Packett Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Reviewed-by: Konrad Dybcio Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Link: https://lore.kernel.org/r/20260201210230.911220-1-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5c9ab0c9cede9f149733d330e2d7d45341b71359 Author: Gou Hao Date: Mon Jul 27 18:42:13 2026 +0800 powerpc/xive: propagate IPI init errors to prevent use-after-free [ Upstream commit 411a3c016e7a95f5fa105a0587e07d0647a77727 ] When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free. Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Fixes: cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs") Signed-off-by: Gou Hao Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-4-gouhao@uniontech.com Signed-off-by: Sasha Levin commit e3388edec1fff206a658aaf8ee8ab87eea892cc6 Author: Gou Hao Date: Mon Jul 27 18:42:12 2026 +0800 powerpc/xive: add error return value to xive_smp_probe() [ Upstream commit ab5ae5dceb86614f6c9e7488f91b652000edfdc5 ] xive_smp_probe() calls xive_init_ipis() which can fail, but its return value is currently ignored. Change xive_smp_probe() to return int so that errors can be propagated to callers. This is a preparatory patch for the next one. No functional change yet; the return value is always 0 at this point. Signed-off-by: Gou Hao Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-3-gouhao@uniontech.com Stable-dep-of: 411a3c016e7a ("powerpc/xive: propagate IPI init errors to prevent use-after-free") Signed-off-by: Sasha Levin commit ebdd932dc24c1cf7cc31710b7730515e4e66d886 Author: Rafael J. Wysocki Date: Wed Aug 12 14:41:44 2026 +0200 ACPI: bus: Introduce acpi_bus_get_primary_device() [ Upstream commit 72530e1f72b0515a73fd88292254d04fecf03649 ] The function used for obtaining the first "physical" device for which the given ACPI one is the ACPI companion, acpi_get_first_physical_node(), may return a stale device pointer (mostly in theory) because acpi_unbind_one() may run as a whole after dropping the ACPI device's physical_node_lock in acpi_get_first_physical_node() and before it returns. The last reference to the "physical" device may be dropped then before the pointer to it is returned to the caller. If that happens and the acpi_get_first_physical_node() caller invokes get_device() on the pointer obtained from it, which is done by the majority of its callers, a use-after-free will occur. To prepare for addressing this problem, introduce a new function for getting the first "physical" device associated with the given ACPI one (the "primary physical device") that will also reference count the device in question before returning a pointer to it. Make that new function and acpi_get_first_physical_node() share the physical node list lookup code. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/2843318.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Sasha Levin commit 041cce629a08d4a2f1a28ec61a105b26b7f047e6 Author: Nitin Gote Date: Fri Aug 14 13:11:07 2026 +0530 drm/xe: don't WARN on kernel job timeout when device already wedged [ Upstream commit 13087ad7817e6e5f210064518bfc4d6d58a9c2f3 ] igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2 (UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind, a GSC proxy kernel submission can still time out; with the device wedged and the GuC CT stopped it can never complete, so its kernel job times out. Tile0: GT1: Kernel-submitted job timed out WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:... at guc_exec_queue_timedout_job() Workqueue: gt-ordered-wq drm_sched_job_timedout Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even though the device is already wedged. The timeout handler then treats the kernel queue timeout as unexpected and taints the kernel. Honour an already-wedged device even for killed queues so the expected teardown timeout no longer trips the WARN. Fixes: 5a2f117a80c2 ("drm/xe: Do not wedge device on killed exec queues") Cc: Matthew Brost Signed-off-by: Nitin Gote Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20260814074106.92670-2-nitin.r.gote@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 40bab0da844c142431a6b1cc21b4cf53491dac44 Author: Chris Mason Date: Sat May 30 09:19:19 2026 -0400 nfsd: convert nfsd_net boolean flags to unsigned long flags word [ Upstream commit 11a5fe42e1811f793e04ef885b639ea7668f439d ] nfsd_net contains several boolean fields that are accessed from concurrent contexts without serialization. In particular, nfsd4_end_grace() guards its drain path with a plain bool: if (nn->grace_ended) return; nn->grace_ended = true; The read and the write are independent, and nothing in struct nfsd_net serializes them. At least two contexts can reach this code with no lock held: laundromat path laundry_wq kworker nfs4_laundromat() nfsd4_end_grace() RECLAIM_COMPLETE path nfsd compound kthread nfsd4_reclaim_complete() inc_reclaim_complete() nfsd4_end_grace() Both callers can observe grace_ended == false on different CPUs, both store true, and both proceed into nfsd4_record_grace_done(), which invokes the active client_tracking_ops->grace_done callback. For tracking ops that drain reclaim_str_hashtbl (legacy_tracking_ops via nfsd4_recdir_purge_old, and the cld v1+ ops via nfsd4_cld_grace_done), grace_done calls nfs4_release_reclaim(), which walks every bucket of reclaim_str_hashtbl with no lock and calls nfs4_remove_reclaim_record() (list_del + kfree) on each entry. Two concurrent walkers corrupt the list and double-free every nfs4_client_reclaim. A concurrent nfsd4_find_reclaim_client() iterating the same bucket reads through freed memory. A third call site exists in nfs4_state_start_net() on the skip_grace startup path, but it runs under nfsd_mutex before any client has connected and before the laundromat's first delayed work fires, so it cannot race with the two callers above. Replace the scattered boolean fields in nfsd_net with a single unsigned long flags word and an enum nfsd_net_flag for the bit positions. The grace_ended race is fixed by using test_and_set_bit(), which is atomic on all architectures. The remaining flags (grace_end_forced, in_grace, somebody_reclaimed, track_reclaim_completes, nfsd_net_up, lockd_up) are converted to use test_bit/set_bit/clear_bit for consistency. This avoids sub-word cmpxchg issues on architectures like Hexagon that only support word-sized atomic operations. Fixes: 362063a595be ("nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-3-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 65aa0a4c4c1bffc5afead974876df24e5a2fe00f Author: NeilBrown Date: Sat Dec 13 13:42:00 2025 -0500 nfsd: use workqueue enable/disable APIs for v4_end_grace sync [ Upstream commit 27e383ddeb3c88e20874c545285f2dce1a98f56a ] "nfsd: provide locking for v4_end_grace" introduced a client_tracking_active flag protected by nn->client_lock to prevent the laundromat from being scheduled before client tracking initialization or after shutdown begins. That commit is suitable for backporting to LTS kernels that predate commit 86898fa6b8cd ("workqueue: Implement disable/enable for (delayed) work items"). However, the workqueue subsystem in recent kernels provides enable_delayed_work() and disable_delayed_work_sync() for this purpose. Using this mechanism enable us to remove the client_tracking_active flag and associated spinlock operations while preserving the same synchronization guarantees, which is a cleaner long-term approach. Signed-off-by: NeilBrown Tested-by: Li Lingfeng Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: 11a5fe42e181 ("nfsd: convert nfsd_net boolean flags to unsigned long flags word") Signed-off-by: Sasha Levin commit 96d4b275281b45aacd0f0510fa8bec85d9f7dc5a Author: Bryam Vargas Date: Fri Jul 17 06:26:54 2026 -0500 dm-pcache: validate seg_id fields from persistent memory [ Upstream commit 90c990a68460d7b5720e5634cf650eccdf0f4098 ] cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 3d8391d3149a1aeb93505a4f9fb9ed8364882c42 Author: Evgenii Burenchev Date: Mon Jun 29 15:58:50 2026 -0500 drm/amd/display: Fix dangling pointer in plane reset function [ Upstream commit 98cad4bd1443975d972f4c7f705980da03722a22 ] amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes") Signed-off-by: Evgenii Burenchev Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260629090435.9729-3-evg28bur@yandex.ru [adjust for movement around current amd-staging-drm-next] Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3a03827bb3cda1527aa923f18160c449f2b4cf2c Author: Evgenii Burenchev Date: Mon Jun 29 15:58:56 2026 -0500 drm/amd/display: Fix dangling pointer in CRTC reset function [ Upstream commit 0aeed866cb938943908c3ba46422128e49d2d080 ] amdgpu_dm_crtc_reset_state() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state") Signed-off-by: Evgenii Burenchev Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260629090435.9729-4-evg28bur@yandex.ru [adjust for movement around current amd-staging-drm-next] Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7 Author: Alex Bereza Date: Thu Apr 2 09:46:22 2026 +0200 dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout [ Upstream commit aa99c4d1d63bbc26a5fc4c667d89b2595743c19d ] Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT. Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value. Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's") Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") Reviewed-by: Suraj Gupta Reviewed-by: Frank Li Signed-off-by: Alex Bereza Link: https://patch.msgid.link/20260402-fix-atomic-poll-timeout-regression-v4-1-f30d6a6c13cb@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7abc9b49ad01a179e893ba137364a560e21b09f8 Author: Jiri Olsa Date: Fri Jul 3 13:49:09 2026 +0200 uprobes/x86: Move optimized uprobe from nop5 to nop10 [ Upstream commit 554ba38456dad8053a1a80afe6ae6da9eff745cc ] Andrii reported an issue with optimized uprobes [1] that can clobber redzone area with call instruction storing return address on stack where user code may keep temporary data without adjusting rsp. Fixing this by moving the optimized uprobes on top of 10-bytes nop instruction, so we can squeeze another instruction to escape the redzone area before doing the call, like: lea -0x80(%rsp), %rsp call tramp Note the lea instruction is used to adjust the rsp register without changing the flags. We use nop10 and following transformation to optimized instructions above and back as suggested by Peterz [2]. Optimize path (int3_update_optimize): 1) Initial state after set_swbp() installed the uprobe: cc 2e 0f 1f 84 00 00 00 00 00 From offset 0 this is INT3 followed by the tail of the original 10-byte NOP. After a previous unoptimization bytes 5..9 may still contain the old call instruction, which remains valid for threads already there. 2) Rewrite the LEA tail and call displacement: cc [8d 64 24 80 e8 d0 d1 d2 d3] From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not executable entry points while byte 0 is trapped. 3) Publish the first LEA byte: [48] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this is: lea -0x80(%rsp), %rsp call Unoptimize path (int3_update_unoptimize): 1) Initial optimized state: 48 8d 64 24 80 e8 d0 d1 d2 d3 Same as 3) above. 2) Trap new entries before restoring the NOP bytes: [cc] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this traps. A thread that had already executed the LEA can still reach the intact CALL at offset 5. 3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped and byte 5 as CALL. cc [2e 0f 1f 84] e8 d0 d1 d2 d3 From offset 0 this still traps. Offset 5 is still the CALL for any thread that was already past the first LEA byte. 4) Publish the first byte of the original NOP: [66] 2e 0f 1f 84 e8 d0 d1 d2 d3 From offset 0 this is the restored 10-byte NOP; the CALL opcode and displacement are now only NOP operands. Offset 5 still decodes as CALL for a thread that was already there. Tthere is only a single target uprobe-trampoline for the given nop10 instruction address, so the CALL instruction will not be changed across unoptimization/optimization cycles. Therefore, any task that is preempted at the CALL instruction is guaranteed to observe that CALL and not anything else. Note as explained in [2] we need to use following nop10: PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1) which means we need to allow 0x2e prefix which maps to INAT_PFX_CS attribute in is_prefix_bad function. Also changing the uprobe syscall error when called out of uprobe trampoline to -EPROTO, so we are able to detect the fixed kernel. The optimized uprobe performance stays the same: uprobe-nop : 3.129 ± 0.013M/s uprobe-push : 3.045 ± 0.006M/s uprobe-ret : 1.095 ± 0.004M/s --> uprobe-nop10 : 7.170 ± 0.020M/s uretprobe-nop : 2.143 ± 0.021M/s uretprobe-push : 2.090 ± 0.000M/s uretprobe-ret : 0.942 ± 0.000M/s --> uretprobe-nop10: 3.381 ± 0.003M/s usdt-nop : 3.245 ± 0.004M/s --> usdt-nop10 : 7.256 ± 0.023M/s [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t Closes: https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes") Reported-by: Andrii Nakryiko Assisted-by: Codex:GPT-5.5 Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Link: https://patch.msgid.link/20260703114917.238144-6-jolsa@kernel.org Signed-off-by: Sasha Levin commit cf08ff2255de98cfcbc8bf7236fbeb38f0d5b4f1 Author: Yiyang Chen Date: Tue Jun 30 08:41:26 2026 +0000 bpf: Reject MEM_ALLOC BTF accesses past object bounds [ Upstream commit 9c9ee0324c774490ae953162aaaf4561d222bd93 ] BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either. Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new") Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Signed-off-by: Yiyang Chen Reviewed-by: Amery Hung Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/4b8c8a81102ba4b595011434c881194f264ddc59.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 644cf4e77c2770d4246f6d12f99bc80d253b0ec6 Author: Nicholas Dudar Date: Wed Oct 7 23:05:32 2026 -0400 bpf: Reject writes through untrusted BTF pointers [ Upstream commit ac65c710cc643cbc52b899627577357867249530 ] check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases. Fixes: 282de143ead9 ("bpf: Introduce allocated objects support") Signed-off-by: Nicholas Dudar Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Eduard Zingerman Reviewed-by: Amery Hung Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 16a82add1918d3aae1e0b68c0a983b6fc64f5062 Author: Armin Wolf Date: Fri Jun 12 19:34:50 2026 +0200 platform/x86: dell-wmi-base: Fix handling of ultra performance key [ Upstream commit adfd6846bea13667ff28f8aaf00c32fbd69825ab ] The commit message of commit 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so "buffer" already starts after those two fields. Use the correct index for accessing the first data field to avoid a potential buffer overread. Fixes: 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 93a20b14f8627b2d3486e3ec1d3f2e7275a506ec Author: Nicholas Dudar Date: Thu Jul 9 11:58:36 2026 -0400 bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max [ Upstream commit 2aaf67f0516fde29620d0edfc29c01b9ea7ad430 ] check_kfunc_args() detects a kfunc argument named rdonly_buf_size or rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64, and does not bound it. check_kfunc_call() later copies that value into the returned register's mem_size field: meta->r0_size = reg->var_off.value; ... regs[BPF_REG_0].mem_size = meta.r0_size; regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set gets truncated instead of causing a load-time rejection, so the verifier records a PTR_TO_MEM register with an approximately 4 GiB mem_size for whatever allocation the kfunc returned. A later access check against that register uses the truncated, wrong bound. Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the point meta->r0_size is set. Fixes: eb1f7f71c126 ("bpf/verifier: allow kfunc to return an allocated mem") Signed-off-by: Nicholas Dudar Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260709155837.1879230-2-main.kalliope@gmail.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 0203146ad450932c2d3132e367a99c49efe3122d Author: Qing Ming Date: Tue May 19 22:33:19 2026 +0800 usb: gadget: uac: validate rate list length before storing [ Upstream commit 844d83d5964b87919b958ff48405188c6ddae9cc ] UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UAC_MAX_RATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++]. Writing more than ten rates therefore writes past the end of the p_srates[] or c_srates[] array in struct f_uac1_opts or struct f_uac2_opts. With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the UAC1 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac1.c:1669:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac1_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 The same reproducer against the UAC2 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac2.c:2087:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac2_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 Reject additional tokens once UAC_MAX_RATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths. Fixes: 695d39ffc2b5 ("usb: gadget: f_uac1: Support multiple sampling rates") Fixes: a7339e4f5788 ("usb: gadget: f_uac2: Support multiple sampling rates") Signed-off-by: Qing Ming Link: https://patch.msgid.link/20260519143319.147494-1-a0yami@mailbox.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8410cd2690d463b60527d00ac8cffea2d5a041f6 Author: Marco Scardovi Date: Wed Jun 17 17:51:04 2026 +0200 platform/x86: asus-wmi: fix resource leaks on probe failure [ Upstream commit ef3daa2b84a2b8499ce9e2ce1c865dca36d39f95 ] During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations. Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves") Fixes: 2c97d3e55b70 ("platform/x86: asus-wmi: add support for ASUS screenpad") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi Link: https://patch.msgid.link/20260617155104.10111-1-scardracs@disroot.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 1ad6456898f6e6cf58be83bdb607acb1119a9cd1 Author: Maher Azzouzi Date: Sun Jul 12 18:05:30 2026 +0100 esp: do not unref managed frag pages in esp_ssg_unref() [ Upstream commit 21697720ff43b8dfa25b8e8d9ca7f56f4597fc80 ] esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data(). Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Maher Azzouzi Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 80968b42d13080bf7bc1f3ee17fef126ce2ad98f Author: Leon Romanovsky Date: Mon Jul 13 07:41:23 2026 -0400 RDMA/rvt: Return NULL after port allocation failure [ Upstream commit 2982eaf3b9d2d953318c74cd6f1b7576ea6d7b1f ] rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free. Return NULL immediately after deallocation so callers can propagate the allocation failure. Fixes: ff6acd69518e ("IB/rdmavt: Add device structure allocation") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-1-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6a2e023429a41afd0d9dfe74268aa51774a953ff Author: Reinette Chatre Date: Mon Jul 13 10:39:43 2026 -0700 fs/resctrl: Fix UAF from worker threads when domains are removed [ Upstream commit 2566b5cd6a275c124e8f154fef6e815f92ec8d5c ] The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains. Fixes: 24247aeeabe9 ("x86/intel_rdt/cqm: Improve limbo list processing") Closes: https://sashiko.dev/#/patchset/20260429184858.36423-1-tony.luck%40intel.com # [1] Reported-by: Sashiko Co-developed-by: Tony Luck Signed-off-by: Tony Luck Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/3f0e0752deb3421606dfc4600f0ab3a4ae098cd7.1783963505.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit c6492e17412048387435f256ffafc4dd6518db28 Author: Dave Jiang Date: Thu Jul 9 08:58:41 2026 -0700 cxl/features: Serialize multi-part Get/Set Feature transfers [ Upstream commit 77b814c1832fde018c30357b4ec3fcdaa91a1c10 ] A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=1 Fixes: 5e5ac21f629d ("cxl/mbox: Add GET_FEATURE mailbox command") Fixes: 14d502cc2718 ("cxl/mbox: Add SET_FEATURE mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Richard Cheng Link: https://patch.msgid.link/20260709155841.1895915-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit a60bc2df2d323cc1342f0cf95563cae266801e20 Author: Sudeep Holla Date: Tue Jul 14 13:56:34 2026 +0100 firmware: arm_scmi: Fix SCMI device destroy lifetimes [ Upstream commit 6abe8fe36b29ff51d1a42c2f338972883f4751a5 ] scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again. Fixes: 9ca67840c0dd ("firmware: arm_scmi: Balance device refcount when destroying devices") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-15-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f85333284fcb682cc39e9c29297575ae534d364d Author: Sudeep Holla Date: Tue Jul 14 13:56:31 2026 +0100 firmware: arm_scmi: Fix OF node reference handling [ Upstream commit 659705f5eb378cea462214b74bdc6240cdab53fc ] SCMI devices store the DT node in dev.of_node through device_set_node(), but that helper only assigns the fwnode and of_node pointers without taking an OF node reference. Take a reference when assigning the node and release it from the SCMI device release path. With the device owning that reference, remove the separate channel-side get/put pair from the core driver. Fixes: 96da4a99ce50 ("firmware: arm_scmi: Set fwnode for the scmi_device") Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-12-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Stable-dep-of: 6abe8fe36b29 ("firmware: arm_scmi: Fix SCMI device destroy lifetimes") Signed-off-by: Sasha Levin commit 21bc07293ec4f05667a8e6076113c4a1c9973e4c Author: Sudeep Holla Date: Tue Jul 14 13:56:30 2026 +0100 firmware: arm_scmi: Clear SystemPower flag on create failure [ Upstream commit e4c16ae24ca027d7a72d645b42f976bb3e99b4b0 ] __scmi_device_create() reserves the singleton SystemPower protocol device before registering the SCMI device. If any later step fails, a stale reservation can make a later retry reject SystemPower device creation permanently, for example after probe deferral. A plain global boolean is not enough to track the reservation. A delayed final release of an older SystemPower device could clear the boolean after a newer device has already claimed it, breaking the singleton guarantee for the active device. Track the reservation with the scmi_device pointer itself. Claim it with cmpxchg(NULL, scmi_dev) after allocating the device object, and release it with cmpxchg(scmi_dev, NULL) from the common cleanup helper. This lets the create-failure, explicit destroy and final release paths clear only the reservation owned by the device being cleaned up. Fixes: 2c3e674465e7 ("firmware: arm_scmi: Refactor device create/destroy helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-11-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Stable-dep-of: 6abe8fe36b29 ("firmware: arm_scmi: Fix SCMI device destroy lifetimes") Signed-off-by: Sasha Levin commit 074d0620401974cbfa9b63684cdfae99c7b2059c Author: Aditya Prakash Srivastava Date: Fri Jun 26 05:48:21 2026 +0000 ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find() [ Upstream commit 03438084a7b8621fb5c762dd3d04cff5f2630fb2 ] Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option). The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry. To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API. If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle. Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window. If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures. Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety. In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search. Suggested-by: Jan Kara Reported-by: Colin Ian King Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219283 Fixes: 0a46ef234756 ("ext4: do not create EA inode under buffer lock") Signed-off-by: Aditya Prakash Srivastava Tested-by: Colin Ian King Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260626054821.1729-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 094f0a895cf97a993d06d5dc4c12e7cb7da845a5 Author: Leon Hwang Date: Wed Jul 22 23:19:08 2026 +0800 bpf: Fix WARNING in bpf_tracing_link_release [ Upstream commit 61aaa8782bec59ecffd22e030f54ef9351bcabf9 ] The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier. 1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became 'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the trampoline would poke the target prog's nop insn using jmp insn instead of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target. 'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in 'tr->flags', the trampoline will fail to restore the prog's nop insn using call insn. [ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98 ... [ 3.428793] bpf_link_free+0x58/0x130 [ 3.429293] bpf_link_release+0x23/0x30 Fix the warning by updating 'tr->flags' with '|=' and lock. Fixes: 2b5dcb31a19a ("bpf, x64: Fix tailcall infinite loop") Signed-off-by: Leon Hwang Reviewed-by: Pu Lehui Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20260722151909.69142-2-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 01b5fcdc30c0ab35af960b60508eae1f7f7d32fd Author: Justin Yeh Date: Thu Jul 23 11:58:12 2026 +0800 pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip [ Upstream commit 9c650317ba553d297f3fc5f0ae40ec53d86f9dab ] The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free. Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away. Fixes: a6df410d420a ("pinctrl: mediatek: Add Pinctrl/GPIO driver for mt8135.") Fixes: 805250982bb5 ("pinctrl: mediatek: add pinctrl-paris that implements the vendor dt-bindings") Fixes: e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that implements the generic pinctrl dt-bindings") Signed-off-by: Justin Yeh Reviewed-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f3480c59f4ce97d831e9d06f5a2b9c20547ed1a4 Author: Li Qiang Date: Fri Jul 17 23:39:08 2026 +0800 scsi: ufs: core: Validate string descriptors [ Upstream commit d96e83d028d7d8762e424e49c671d49ac2ecf14f ] The string descriptor length includes a two-byte header while the UTF-16 payload starts after it. utf16s_to_utf8s() expects a count of UTF-16 code units, not bytes. Passing the payload byte count can make it read beyond the descriptor buffer. Validate that the payload has an even byte count, pass a code-unit count to the converter, and allocate sufficient UTF-8 output space. The raw string buffer starts after the descriptor header but its size is bLength. Copying bLength bytes from that pointer can read beyond the response buffer. Allocate a zeroed bLength-sized buffer and copy only the UTF-16 payload. This preserves the raw buffer size consumed by the RPMB device-ID ABI while avoiding the overread. Fixes: 4b828fe156a6 ("scsi: ufs: revamp string descriptor reading") Fixes: d794b499f948 ("scsi: ufs: core: fix incorrect buffer duplication in ufshcd_read_string_desc()") Signed-off-by: Li Qiang Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260717153914.26321-2-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9d39f6dda00f6745fe711b67de77fbef79e4c41a Author: Bean Huo Date: Sat Nov 8 00:05:16 2025 +0100 scsi: ufs: core: Convert string descriptor format macros to enum [ Upstream commit 0d9a7085ec24983b5b8a4971c0eb6c756c75f1bf ] Convert SD_ASCII_STD and SD_RAW from boolean macros to enum values for improved code readability. This makes ufshcd_read_string_desc() calls self-documenting by using explicit enum values instead of true/false. Move the ufshcd_read_string_desc() declaration from include/ufs/ufshcd.h to drivers/ufs/core/ufshcd-priv.h since this function is not exported. Co-developed-by: Bart Van Assche Signed-off-by: Bart Van Assche Suggested-by: Avri Altman Signed-off-by: Bean Huo Link: https://patch.msgid.link/20251107230518.4060231-2-beanhuo@iokpp.de Signed-off-by: Martin K. Petersen Stable-dep-of: d96e83d028d7 ("scsi: ufs: core: Validate string descriptors") Signed-off-by: Sasha Levin commit 268cbe3a36ae57a2ec09601f343b92f6f092d505 Author: Nicolin Chen Date: Tue Jul 14 13:55:02 2026 -0700 iommu/tegra241-cmdqv: Don't fall back to a freed smmu after devm_krealloc() [ Upstream commit d4d05f55e9da646ec03adfa77260eb46f4163749 ] __tegra241_cmdqv_probe() uses devm_krealloc() to grow @smmu into the larger tegra241_cmdqv, which frees the original @smmu once it relocates. A failure after that returned NULL, and the caller then dereferenced the freed @smmu on its fallback path. Return an int and take @smmu by reference instead, then update *smmu to the reallocated pointer after devm_krealloc() succeeds, so the caller and its fallback path both use the live @smmu rather than the freed original. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c36816feff47f676dcc51919777d483f4146c1ee Author: Gary Guo Date: Thu Jul 23 23:00:48 2026 +0100 PCI: Fix UAF when probe runs concurrent to dyn ID removal [ Upstream commit 3ffc4c9690c33ee28cdb3d0182b12f9c623e3acc ] Dynamic IDs are only guaranteed to be valid when dynids.lock is held, as remove_id_store() can free the node. Thus, make a copy in pci_match_device(). Also, clarify that the id parameter is only valid during probe. Fixes: 0994375e9614 ("PCI: add remove_id sysfs entry") Reported-by: Sashiko Link: https://lore.kernel.org/all/20260619170503.518F61F00A3A@smtp.kernel.org/ Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-pci_id_fix-v4-9-3580726844e1@garyguo.net Signed-off-by: Sasha Levin commit 5e81d109f2e24b0e47483104566936d85ff63e3e Author: Gary Guo Date: Thu Jul 23 23:00:47 2026 +0100 PCI: Fix dyn_id add TOCTOU [ Upstream commit 04fde70f782b6ce984f9f80c2023786caea28287 ] Currently there is a TOCTOU issue in new_id_store() as the dyn ID insertion in pci_add_dynid() and the pci_match_device() are in separate critical sections. Fix this by moving the existing ID check to inside pci_add_dynid() and only check against the static ID table outside the critical section. Fixes: 3853f9123c18 ("PCI: Avoid duplicate IDs in driver dynamic IDs list") Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-pci_id_fix-v4-8-3580726844e1@garyguo.net Stable-dep-of: 3ffc4c9690c3 ("PCI: Fix UAF when probe runs concurrent to dyn ID removal") Signed-off-by: Sasha Levin commit 0787e34b894bd53708530ecb6bf987c874a2ffc9 Author: Gary Guo Date: Thu Jul 23 23:00:46 2026 +0100 PCI: Make pci_match_one_device() match on ID instead of device [ Upstream commit c967b365d7b51c2297d9be5df39ac3e20638faf4 ] PCI dynamic ID needs to match IDs against a new ID to see if it already exists. Existing APIs can only match IDs against devices, so the dynamic ID insertion code creates a temporary device only for matching purposes. Rename pci_match_one_device() to pci_match_one_id() so it can be used for this purpose instead; add a pci_id_from_device() helper to make it easy to convert users. Similarly, convert pci_match_id() to do_pci_match_id(). But keep the existing API because there are many users. Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-pci_id_fix-v4-7-3580726844e1@garyguo.net Stable-dep-of: 3ffc4c9690c3 ("PCI: Fix UAF when probe runs concurrent to dyn ID removal") Signed-off-by: Sasha Levin commit 2fcd26f4680143e9ec477069530548dbe20fce6f Author: Leon Romanovsky Date: Wed Jul 29 07:21:28 2026 -0400 RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry() [ Upstream commit 373f3716a2de7adc739269ebb4d87e5bf4dc180c ] When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free. Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem(). Fixes: 0f8ab0b6e91b ("RDMA/iw_cxgb4: Low resource fixes for Memory registration") Link: https://patch.msgid.link/20260726-leaked-mhp-dereg-skb-in-c4iw-dereg-m-v1-1-ebd6df364d53@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ffd56ada81f975a33f1df447f1bec9090a818e98 Author: Guixin Liu Date: Wed Jul 29 18:56:07 2026 +0800 nvmet: fix return status of RMI log page on allocation failure [ Upstream commit 581d8bb556dd3e5567bcf322aa5e3e4b6a200c08 ] nvmet_execute_get_log_page_rmi() leaves 'status' holding NVME_SC_SUCCESS (set by the successful nvmet_req_find_ns() call) when the kzalloc() for the log buffer fails. It then jumps to the out label and completes the request with a success status, so the host is told the command succeeded while no data was transferred. Initialize 'status' to NVME_SC_INTERNAL, matching the smart log handler, so an allocation failure is reported as an internal error. Fixes: 5fd075cdaf36 ("nvmet: implement rotational media information log") Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit f2be47fa8e225968eb66863657143fe900ec4bca Author: Adrián Larumbe Date: Mon Jul 20 16:48:41 2026 +0100 drm/panthor: Add vm_bind region with kbo range overlap check [ Upstream commit 985f5e12f3cdf43030e13c2bbd154913133b5c3f ] When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources. Fixes: 12cf826bf1dd ("drm/panthor: Support sparse mappings") Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Boris Brezillon Signed-off-by: Adrián Larumbe Reviewed-by: Steven Price Link: https://patch.msgid.link/20260720-vm_bind_checks-v6-1-c2c7dbe93a73@collabora.com Signed-off-by: Steven Price Signed-off-by: Sasha Levin commit 23bed4ef132c55c9016f0c6122c8b8ba2efa2353 Author: Jeff Johnson Date: Fri Jul 24 08:56:13 2026 -0700 wifi: ath12k: fix overreads in ath12k_wmi_process_csa_switch_count_event() [ Upstream commit 878654eb78c6aa0ff585baf1376567c775ca28ec ] There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath12k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath12k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260724-ath12k_wmi_process_csa_switch_count_event-cleanup-v2-1-02a45d7246c0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ffcc9ea4e4d121c78aef6654a1577aa7d120774d Author: Abd-Alrhman Masalkhi Date: Sun Jun 28 14:27:37 2026 +0000 md: remove REQ_NOWAIT support from raid1/10/456 [ Upstream commit 3fe5b7c9fb72ccc29bfd0f955b124892af7e3674 ] REQ_NOWAIT support in md personalities that can block internally is fundamentally incomplete. While reads can avoid some blocking paths, write requests can still encounter cases where one mirror succeeds while another returns -EAGAIN. At that point md cannot distinguish queue pressure from a real device failure, so it can neither record a bad block nor safely retry the write without REQ_NOWAIT, leaving mirrors with divergent data. Rather than continue advertising REQ_NOWAIT support for personalities that cannot implement it correctly, remove it from raid1, raid10 and raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to their underlying devices; stacked limits will still clear the feature if any component device lacks REQ_NOWAIT support. Fixes: bf2c411bb1cf ("md: raid456 add nowait support") Fixes: c9aa889b035f ("md: raid10 add nowait support") Fixes: 5aa705039c4f ("md: raid1 add nowait support") Fixes: f51d46d0e7cb ("md: add support for REQ_NOWAIT") Suggested-by: Yu Kuai Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260628142737.1051059-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 7a1b971b799eae8a957acb90d8100576df889644 Author: Shayne Chen Date: Mon Jul 20 17:01:02 2026 +0800 wifi: mt76: fix handling channel context with different bands in mt76_switch_vif_chanctx() [ Upstream commit 70869cc429fffc77de51e7777c0ecb651e8fca07 ] When performing channel switches on different radios within a short timeframe, channel contexts with different bands can be carried for each struct ieee80211_vif_chanctx_switch. Rework mt76_switch_vif_chanctx() to properly handle this scenario. Fixes: 82334623af0c ("wifi: mt76: add chanctx functions for multi-channel phy support") Co-developed-by: Rex Lu Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260720090102.190729-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2aa3d3b9fac9163e9226e35556607ae3f75be21e Author: Eason Lai Date: Wed Jul 1 09:06:54 2026 +0800 wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete [ Upstream commit 217f9e7bb02558759be9d9ecfe532e9708741c50 ] A use-after-free issue occurs in mt76_rx_poll_complete due to a race condition. The STA has already been removed, but the rx_status still had a pointer to the wcid in the STA. Set the links' wcid pointers to be NULL for a MLD in mt7925_sta_pre_rcu_remove() BUG: KASAN: invalid-access in mt76_rx_poll_complete+0x280/0x470 Call trace: dump_backtrace+0xec/0x128 show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc8 print_report+0x1b8/0x710 kasan_report+0xe0/0x144 do_bad_area+0x120/0x260 do_tag_check_fault+0x20/0x34 do_mem_abort+0x54/0xa8 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x40/0xcc el1h_64_sync+0x7c/0x80 mt76_rx_poll_complete+0x280/0x470 mt76_dma_rx_poll+0x114/0x51c mt792x_poll_rx+0x60/0xf8 napi_threaded_poll_loop+0xe0/0x450 napi_threaded_poll+0x80/0x9c kthread+0x11c/0x158 ret_from_fork+0x10/0x20 Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Eason Lai Link: https://patch.msgid.link/20260701010654.956863-1-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit aca0cd273b486a078f936b3fb409e619673521b1 Author: Felix Fietkau Date: Fri Jul 24 12:47:54 2026 +0000 wifi: mt76: cancel reset and rc work on device unregister [ Upstream commit e995d3dccc9d980af13a60ad37409ed1561f9eeb ] Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/20260724124813.3961474-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9a9e902bd0556052534641f7d5f868c6dc4b84ae Author: Yonghong Song Date: Tue Jul 28 22:01:59 2026 -0700 bpf: Reject >8 byte return values on return-reading trampoline paths [ Upstream commit c48796aa6c392cde93946e5d5a9a1f1b1cf72feb ] btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0. But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation. This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected. Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init(). Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") Signed-off-by: Yonghong Song Reviewed-by: Eduard Zingerman Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260729050159.2585809-1-yonghong.song@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e512823aabbdc91444b9d886638f059ef58e86b1 Author: Felix Fietkau Date: Fri Jul 24 12:48:10 2026 +0000 wifi: mt76: mt7996: clear stale link state on full reset [ Upstream commit 75d2a4e2129b58bb0ddb842387299038495aad2a ] After a full chip reset, mac80211 reconfig replays interface, link and channel context setup. mt7996_vif_link_add() short-circuits when the link_id is still marked in mvif->valid_links, a state introduced for postponing link teardown to interface removal. The reset path frees the link structures without clearing those bits, so the replayed setup never re-creates dev_info/bss_info/STA records in the restarted firmware and never re-registers the link wcid, leaving the device inoperative. The reset path also leaks every allocated MLD index: per-link indices and the per-vif group/remap indices are re-allocated from scratch during reconfig, but the old bits stay set in the masks, so repeated full resets exhaust the index space. Clear valid_links in the reset vif iterator and reset the MLD index masks alongside the existing omac_mask clearing. Fixes: ace5d3b6b49e ("wifi: mt76: mt7996: improve hardware restart reliability") Fixes: 08813703ac41 ("wifi: mt76: mt7996: Destroy vif active links in mt7996_remove_interface()") Link: https://patch.msgid.link/20260724124813.3961474-26-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e9e2854fcff5733ffc607e8ecc87e0e591ab41fd Author: Will Deacon Date: Thu Jul 30 14:26:50 2026 +0100 arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry [ Upstream commit 88b839ce497ccb1ff92f7ae742c78dd2937ba572 ] Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path. Cc: Kees Cook Cc: Jinjie Ruan Cc: Mark Rutland Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org [1] Reported-by: Yiqi Sun Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/ Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") Tested-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0ec1d14cf302ae7c23ec218527b2849a1fced3f4 Author: Zhao Li Date: Fri Jul 31 12:02:44 2026 +0800 wifi: nl80211: clean up color-change beacon data on errors [ Upstream commit 927ee844c47ac2aef22c8f7a35f098ff576b398b ] nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error. Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data. Fixes: dc1e3cb8da8b ("nl80211: MBSSID and EMA support in AP mode") Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260731120244.82628-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f334b26b884dff5d0a558dc464fa55f300868a68 Author: Jason Huang Date: Wed Jul 22 16:26:08 2026 +0800 wifi: brcmfmac: fix P2P action frame handling without device vif [ Upstream commit 1b1edb9ebed49099bdc924cef49a9aea8b552199 ] Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search. Fixes: 30fb1b272909 ("brcmfmac: use actframe_abort to cancel ongoing action frame") Fixes: 6eda4e2c5425 ("brcmfmac: Add tx p2p off-channel support.") Signed-off-by: Jason Huang Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260722082608.412472-1-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9260a92ce90e6a95ce2ffdf1441c5216bf3f9552 Author: Karl Mehltretter Date: Fri Jul 31 20:18:40 2026 +0200 serial: core: do fallible allocations before the console can be registered [ Upstream commit 1a0e4fbce5d9c1bc179a35a2fd9ed142664299e3 ] serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed. Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds. Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration. Fixes: 266dcff03eed ("Serial: allow port drivers to have a default attribute group") Fixes: f7048b15900f ("tty: serial_core: Add name field to uart_port struct") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260719070454.D6FA21F000E9@smtp.kernel.org/ Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-2-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ddf51d74ee9f9857c99477329d80408cedebda61 Author: Karl Mehltretter Date: Fri Jul 31 20:18:41 2026 +0200 serial: core: clear freed pointers on uart_register_driver() failure [ Upstream commit 61a2fb25551be0375bc16ef2a70c987dfca26183 ] uart_register_driver() leaves drv->state pointing to freed memory when tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver also retains a pointer after its reference is dropped. Drivers that use drv->state as an "already registered" flag can then skip registration on the next probe and pass the freed state to uart_add_one_port(). This issue was found with failslab on QEMU's raspi1ap board by failing registration and binding the PL011 port again. Clear both pointers on their failure paths, as uart_unregister_driver() already does. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 9e845abfc8a8 ("serial: fix NULL pointer dereference") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-3-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2af4c46b429907edc8cb069c78fca1d950120b98 Author: Karl Mehltretter Date: Fri Jul 31 20:18:42 2026 +0200 tty: skip cdev_del() when no cdev is registered [ Upstream commit c3b5623fd97648f2747444aa8932ae604662df93 ] TTY device registration can fail before a cdev is allocated. Serial core keeps the port so setserial can still use it, and later removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer dereference. Only delete the cdev when the slot is not NULL. Fixes: a3a10ce3429e ("Avoid usb reset crashes by making tty_io cdevs truly dynamic") Fixes: da4c279942b0 ("serial: enable serdev support") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-4-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2fd9c8112907c14efefe6a90d20b774737052db3 Author: Haoxiang Li Date: Tue Jun 23 14:52:00 2026 +0800 HID: logitech-hidpp: Fix FF device cleanup on init failure [ Upstream commit dd5be4d9ce2dfc4d4a4527ef7d31d21a78e3cdac ] hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue. If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds. Fixes: ff21a635dd1a ("HID: logitech-hidpp: Force feedback support for the Logitech G920") Signed-off-by: Haoxiang Li Reviewed-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 8397942b67128e0b1275cfedb5abf4faafac5fd0 Author: Yang Xiuwei Date: Thu Jul 30 09:09:09 2026 +0800 ublk: validate auto buf reg before taking uring_cmd [ Upstream commit ca5a01eee34c7cbe0f531a613b0292a3ad1a419b ] With UBLK_F_AUTO_BUF_REG, invalid sqe->addr can fail after ublk_fill_io_cmd() has set UBLK_IO_FLAG_ACTIVE. The uring_cmd is completed while the tag stays active, which can hang teardown. Split validation from buffer apply so the check has no side effects, then take the uring_cmd and store the already-validated buffer. Apply the same order in FETCH so io->buf is not written before __ublk_fetch() state checks. Fixes: 52460dda3a77 ("ublk: move auto buffer register handling into one dedicated helper") Suggested-by: Caleb Sander Mateos Signed-off-by: Yang Xiuwei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f81972b235f3ebfa40bdce8bcfee3f242fb24065 Author: Ning Ding Date: Mon Aug 3 04:26:08 2026 -0700 bpf: Invalidate RCU pointers after final spin unlock [ Upstream commit 180c7000712db77063b3a26f4c97e7dd9038f449 ] In a sleepable BPF program, a spin lock can provide the only RCU protection for a kptr. The final bpf_spin_unlock() ends that protection, but the verifier leaves the pointer valid. Another CPU can then free the object before the pointer is used. A capability-limited runtime PoC triggered a task_struct use-after-free in __bpf_get_task_stack(). Record whether the program is in an RCU-protected context before releasing the lock. Invalidate RCU-protected pointers only when the unlock leaves the final such context. This preserves valid pointers in non-sleepable programs and inside an explicit RCU read-side section. Fixes: 5861d1e8dbc4 ("bpf: Allow bpf_spin_{lock,unlock} in sleepable progs") Assisted-by: Codex:gpt-5.6-sol Assisted-by: ChatGPT:GPT-5.6-Pro Signed-off-by: Ning Ding Link: https://lore.kernel.org/bpf/20260803112615.3362122-2-dingning04@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 3556caa31a2bfbc22c11b812fd4ed8851c2d7bff Author: Krzysztof Wilczyński Date: Mon Jul 20 21:15:41 2026 +0000 PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers [ Upstream commit 747b9bbbbdfdee51aee2456388f9b94b5086de4d ] Currently, the legacy I/O and memory sysfs handlers do not check security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and legacy_mem files unprotected when the kernel is locked down. Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") added the check to pci_write_config(), pci_mmap_resource(), and pci_write_resource_io() to prevent userspace from programming DMA-capable hardware that could be used to modify kernel code, but did not cover the legacy handlers. As a result, root can still write arbitrary I/O ports and map the legacy I/O and memory spaces while the kernel is locked down, which is the same capability the lockdown is meant to remove. Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and pci_mmap_legacy_io(). These generic handlers cover both architectures that define HAVE_PCI_LEGACY (such as Alpha and PowerPC). Fixes: eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") Signed-off-by: Krzysztof Wilczyński [bhelgaas: add Link] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260720211541.1509744-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 9b405b3e7e131ee85dd78b9cc951b41f0828a333 Author: Rafael J. Wysocki Date: Tue Aug 4 22:11:27 2026 +0200 thermal: hwmon: Remove hwmon class device along with its parent [ Upstream commit 2b57e24d34b2dfc43c81942bb359d6315bf302fb ] The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type. That turns out to be problematic when the thermal zone holding the hwmon device is removed. For example, say that there are two ACPI thermal zones on a system /sys/devices/virtual/thermal/thermal_zone0/ /sys/devices/virtual/thermal/thermal_zone1/ The current code registers a hwmon class device for thermal_zone0 only: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/ because the type is "acpitz" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input There is also /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input which belongs to thermal_zone0. When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, thermal_remove_hwmon_sysfs() skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress. Address this by making thermal_remove_hwmon_sysfs() remove the entire hwmon class device interface for the given thermal zone type when the thermal zone device holding it is removed. To prevent races with thermal_add_hwmon_sysfs() that may interfere with this, carry out the entire addition and removal of hwmon sysfs interfaces for thermal zones under thermal_hwmon_list_lock. Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to the current kernel coding style to align with the new "unlock" label. Link: https://lore.kernel.org/linux-pm/20260402021828.16556-1-liujia6264@gmail.com/ Fixes: f6b6b52ef7a5 ("thermal_hwmon: Pass the originating device down to hwmon_device_register_with_info") Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/5094738.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit 9d44822ba34d6035690f725f9de602744a6e1946 Author: Cen Zhang Date: Wed Jun 24 17:53:10 2026 +0800 ocfs2: o2hb: quiesce negotiate handlers and timeout work [ Upstream commit 011291b70ba4832e136b7b581825b2bc0f525bf6 ] Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that path: region lifecycle: late negotiate callback: 1. make_item() registers the 1. o2net_process_message() gets a region handlers before heartbeat handler for reg. dev_store() has built a 2. The callback runs after the lookup runnable heartbeat context. lock is dropped and dereferences reg. 2. A failed start or rmdir 3. An approve or timeout path tries to stops the heartbeat thread, queue reg's delayed work, or release quiesces existing work, and races the callback body after handler drops the final configfs ref. unregister. 3. region_release() must drain 4. The callback or delayed work can handler-visible o2net rx work outlive reg unless lifecycle code before freeing reg. keeps the region non-armable and drains the active-or-destroying o2net workqueue. Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600 Link: https://lore.kernel.org/20260624095310.763763-3-zzzccc427@gmail.com Fixes: 34069b886f95 ("ocfs2: o2hb: add NEGO_TIMEOUT message") Fixes: e76f8237a2f7 ("ocfs2: o2hb: add NEGOTIATE_APPROVE message") Signed-off-by: Cen Zhang Assisted-by: Codex:gpt-5.5 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit bf4bd72020f33e9665e22858022cf081a4e98e05 Author: Yufan Chen Date: Mon Mar 30 23:34:28 2026 +0800 ocfs2/heartbeat: fix slot mapping rollback leaks on error paths [ Upstream commit 5686459423d03d192134166f0ec45f98bb2d5d57 ] o2hb_map_slot_data() allocates hr_tmp_block, hr_slots, hr_slot_data, and pages in stages. If a later allocation fails, the current code returns without unwinding the earlier allocations. o2hb_region_dev_store() also leaves slot mapping resources behind when setup aborts, and it keeps hr_aborted_start/hr_node_deleted set across retries. That leaves stale state behind after a failed start. Factor the slot cleanup into o2hb_unmap_slot_data(), use it from both o2hb_map_slot_data() and o2hb_region_release(), and call it from the dev_store() rollback after stopping a started heartbeat thread. While freeing pages, clear each hr_slot_data entry as it is released, and reset the start state before each new setup attempt. This closes the slot mapping leak on allocation/setup failure paths and keeps failed setup attempts retryable. Link: https://lkml.kernel.org/r/20260330153428.19586-1-yufan.chen@linux.dev Signed-off-by: Yufan Chen Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Stable-dep-of: 011291b70ba4 ("ocfs2: o2hb: quiesce negotiate handlers and timeout work") Signed-off-by: Sasha Levin commit 1f0f61573ba4cb899105b5cef65be3ca02205f93 Author: Jiri Olsa Date: Mon Aug 3 23:01:46 2026 +0200 bpf: Clear buf on error in __bpf_get_task_stack [ Upstream commit f5d242825ca417bb6afe35fde6e8880f97ca43fb ] Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM argument and we should initialize the buf on every return path. Adding missing buf memset for __bpf_get_task_stack fail paths. This provides deterministic buffer contents, which is useful when the buffer is used directly as a map key. Fixes: 06ab134ce8ec ("bpf: Refcount task stack in bpf_get_task_stack") Fixes: b992f01e6615 ("bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()") Reported-by: Sashiko Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-10-jolsa@kernel.org Signed-off-by: Sasha Levin commit 35ef785b25ee2add9c8212eef01cbe35a3c711ef Author: Jiri Olsa Date: Mon Aug 3 23:01:45 2026 +0200 bpf: Remove trace_in argument from __bpf_get_stack [ Upstream commit 58cfc2201d964163fe9c4a703136eb64db799f08 ] Now with the new callchain_* helper functions we can process trace_in case directly in bpf_get_stack_pe function and remove it from __bpf_get_stack which makes things easier for preemption fix in following change. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-9-jolsa@kernel.org Stable-dep-of: f5d242825ca4 ("bpf: Clear buf on error in __bpf_get_task_stack") Signed-off-by: Sasha Levin commit 63669625833c4429b06a7d66d0e78b483ca2eaa2 Author: Jiri Olsa Date: Mon Aug 3 23:01:44 2026 +0200 bpf: Factor callchain_finalize function from __bpf_get_stack [ Upstream commit 014fbe5902dccdaef69114abdcdb15e3dbe55e34 ] The new callchain_finalize function calls the build-id retrieval (if needed) and zeroes the buffer. This makes things easier for preemption fix in following change. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-8-jolsa@kernel.org Stable-dep-of: f5d242825ca4 ("bpf: Clear buf on error in __bpf_get_task_stack") Signed-off-by: Sasha Levin commit 8c30d9fd61ebfa613742b862c8f74c36f6984849 Author: Jiri Olsa Date: Mon Aug 3 23:01:43 2026 +0200 bpf: Factor callchain_store function from __bpf_get_stack [ Upstream commit cbb99938e7935c9f62c891573a4b09690e5e22de ] The new callchain_store function stores trace entries buffer into user supplied buffer. It covers both just-ip and buildid data. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-7-jolsa@kernel.org Stable-dep-of: f5d242825ca4 ("bpf: Clear buf on error in __bpf_get_task_stack") Signed-off-by: Sasha Levin commit 562d24ac214ba9530d88841088eb6adce5c537b5 Author: Harry Wentland Date: Thu Jul 16 16:49:06 2026 -0400 drm/amd/display: Resize MST HDCP per-connector arrays to 32 [ Upstream commit 261e0fe4e2c99f687114b64b10b98db964b475f4 ] AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of 32 connectors. But the way it's used is like MAX_DISPLAY_COUNT. Hence we're off by one with DRM core, which supports a max of 32 connectors. Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT to match its actual use, and increase the size to 32 to match the originally intended size. Fixes: 82986fd631fa ("drm/amd/display: save restore hdcp state when display is unplugged from mst hub") Assisted-by: Copilot:claude-opus-4.8 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b5896fc269e9f3b3b4a67a7ce78872bc3bbd3b25 Author: Ray Wu Date: Tue Dec 16 18:09:45 2025 +0800 drm/amd/display: disable replay when crc source is enabled [ Upstream commit a036db3953140d5c2816b056aa3e73b8e98d9bc0 ] [Why] IGT CRC tests fail on replay panels due to invalid CRC values captured when replay is active. [How] - Disable replay when CRC source is enabled; set flag to prevent unexpected re-enable - Reset flag when CRC source is disabled to allow replay Reviewed-by: ChiaHsuan (Tom) Chung Signed-off-by: Ray Wu Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 261e0fe4e2c9 ("drm/amd/display: Resize MST HDCP per-connector arrays to 32") Signed-off-by: Sasha Levin commit d5f3dae82705d9388434892915008da3bb83c4ba Author: Yeoreum Yun Date: Sat Jul 25 12:36:37 2026 +0100 coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable [ Upstream commit 0a47f0be6557b4a851addd430383a4dc7ee08752 ] In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called: - Branch broadcast is selected but not supported by the hardware - etm4_enable_hw() fails This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths. Fixes: 810ac401db1f ("coresight: etm4x: Add complex configuration handlers to etmv4") Suggested-by: Leo Yan Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-6-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit e90f746f4ca3896ca560e820b7b6b0a467026938 Author: Yang Xiuwei Date: Tue Jul 7 11:03:32 2026 +0800 scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails [ Upstream commit bb31844d88b77138b67aa20c3600203baff40140 ] sd_set_special_bvec() allocates a special payload page for UNMAP and WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI midlayer does not call uninit_command() because RQF_DONTPREP is not set yet, leaking the page. Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after freeing the page. Fixes: 81d926e8b552 ("sd: split sd_setup_discard_cmnd") Reviewed-by: Damien Le Moal Signed-off-by: Yang Xiuwei Reviewed-by: John Garry Link: https://patch.msgid.link/20260707030333.22245-3-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit fcee001f57bdbc6a74c5e34f8a2b8065b57db52c Author: Bart Van Assche Date: Wed Jan 14 09:50:50 2026 -0800 scsi: sd: Move the sd_config_discard() function definition [ Upstream commit c0daf4836114fcbdf64bf817cab00b75ce712945 ] Move the sd_config_discard() function definition such that its forward declaration can be removed. Reviewed-by: Damien Le Moal Reviewed-by: Himanshu Madhani Reviewed-by: Johannes Thumshirn Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260114175054.4118163-3-bvanassche@acm.org Signed-off-by: Martin K. Petersen Stable-dep-of: bb31844d88b7 ("scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails") Signed-off-by: Sasha Levin commit ce8103676f4d4b13e1f087fcfb34f80774d30be2 Author: Sun YangKai Date: Thu Jul 9 16:23:35 2026 +0800 btrfs: check if root is readonly when setting posix acl [ Upstream commit 01c2f41fc441f75b3f9326443372faceb1cb6638 ] For a filesystem which has btrfs read-only property set to true, all write operations including acl and xattr should be denied. However, acl can still be set even if btrfs ro property is true. This happens because no function on the set_acl code path checks the root is readonly or not. It was checked in btrfs_setxattr_trans() but got removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans") That commit didn't check if all the callers properly check the root's read-only flag. A previous fix is commit b51111271b03 ("btrfs: check if root is readonly while setting security xattr"). Always check if the root is read-only before performing the set acl operation. Fixes: 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans") Reviewed-by: Johannes Thumshirn Reviewed-by: Filipe Manana Signed-off-by: Sun YangKai Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 172f349f2c59bb8fc5f9fcfe6943b6e262734644 Author: Miquel Sabaté Solà Date: Fri Oct 24 12:21:42 2025 +0200 btrfs: apply the AUTO_K(V)FREE macros throughout the code [ Upstream commit 7ab5d01d58a766807e137cbe8c90cb2e591e2f7d ] Apply the AUTO_KFREE and AUTO_KVFREE macros wherever it makes sense. Since this macro is expected to improve code readability, it has been avoided in places where the lifetime of objects wasn't easy to follow and a cleanup attribute would've made things worse; or when the cleanup section of a function involved many other things and thus there was no readability impact anyways. This change has also not been applied in extremely short functions where readability was clearly not an issue. Signed-off-by: Miquel Sabaté Solà Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 01c2f41fc441 ("btrfs: check if root is readonly when setting posix acl") Signed-off-by: Sasha Levin commit 58b0ab0340ce04a057169d42cbacbf786063813d Author: Johannes Thumshirn Date: Thu Jul 23 17:54:25 2026 +0200 btrfs: zoned: flush active metadata block group at btree_writepages() start [ Upstream commit ecc05eda9a346848ae01a6c8bfa3f0bec133bd8b ] btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress. Fixes: 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 243bf1e45e40be4705aae17c5044bf83df5f4a92 Author: Lu Baolu Date: Wed Aug 5 07:43:11 2026 +0800 iommu/vt-d: Fix iopf_refcount leak on RID domain replacement [ Upstream commit 236dd58fabd2e951b940a6ad88b81147899ed311 ] intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 11dfe2896ea23736c8e0b7f500b4208bee95488c Author: Nicolin Chen Date: Wed Oct 22 19:21:09 2025 -0700 iommu: Pass in old domain to attach_dev callback functions [ Upstream commit fd714986e4e46effa6697b13d32918fc59608ccb ] The IOMMU core attaches each device to a default domain on probe(). Then, every new "attach" operation has a fundamental meaning of two-fold: - detach from its currently attached (old) domain - attach to a given new domain Modern IOMMU drivers following this pattern usually want to clean up the things related to the old domain, so they call iommu_get_domain_for_dev() to fetch the old domain. Pass in the old domain pointer from the core to drivers, aligning with the set_dev_pasid op that does so already. Ensure all low-level attach fcuntions in the core can forward the correct old domain pointer. Thus, rework those functions as well. Suggested-by: Jason Gunthorpe Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Stable-dep-of: 236dd58fabd2 ("iommu/vt-d: Fix iopf_refcount leak on RID domain replacement") Signed-off-by: Sasha Levin commit 6822ba1ae9b6df6a094f7f8998f1da734c85fa19 Author: Chuck Lever Date: Wed Jun 17 08:52:57 2026 -0400 NFS: Return a delegation the client fails to record [ Upstream commit 220af23d863995091f0edeb1e6aa0945b3db8b37 ] When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN. A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition. The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation. Instead of dropping it, hand the delegation back during these error flows. Fixes: ade04647dd56 ("NFSv4: Ensure we honour NFS_DELEGATION_RETURNING in nfs_inode_set_delegation()") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit e4ab436d5ba61e4910fd49d24bb64ddb34d493d6 Author: Ning Ding Date: Mon Aug 10 20:59:54 2026 -0700 bpf: Compare iterator types during state pruning [ Upstream commit 83608e303b95d07afba1c15da0b5d9e513c2f15a ] An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots. Fixes: dfab99df147b ("bpf: teach the verifier to enforce css_iter and task_iter in RCU CS") Signed-off-by: Ning Ding Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260811035955.132989-2-dingning04@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit a25ea67a913f98b8461aff1e9e3a5f6dc2378395 Author: Marek Szyprowski Date: Mon Jul 13 10:56:53 2026 +0200 clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type [ Upstream commit 3b212f9d70805d91febae01d618868f4860e267c ] Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT. Fixes: 7aac482e6290 ("clocksource: samsung_pwm_timer: Make PWM spinlock global") Fixes: f11899894c0a ("clocksource: add samsung pwm timer driver") Signed-off-by: Marek Szyprowski Signed-off-by: Daniel Lezcano Reviewed-by: Krzysztof Kozlowski Reviewed-by: Sebastian Andrzej Siewior Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20260713085653.1145015-1-m.szyprowski@samsung.com Signed-off-by: Sasha Levin commit 6e6f8e3bfc66dff1833a48ecfd857268cff3be84 Author: Maurizio Lombardi Date: Thu Aug 13 15:18:50 2026 +0200 nvmet: fix max_qid race between configfs and controller allocation [ Upstream commit f1a8846e06388113dfdbb89dee005083fa9afdf9 ] The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions. Fixes: 3e980f5995e0 ("nvmet: expose max queues to configfs") Reported-by: syzbot+2626e846cd2585c9aa67@syzkaller.appspotmail.com Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5c6593422eb3c3a21505436ccf74599a433584c8 Author: Usama Arif Date: Fri Aug 14 09:56:37 2026 -0700 blk-iolatency: clear delay state when freeing policy data [ Upstream commit 8935bf22c0a0db517a7f72f7097300e05dd852f5 ] io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, check_scale_change() scales down its peers, and a peer that reaches queue depth one gets blkcg_use_delay() called on it on every further scale-down, even with min_lat_nsec == 0. iolatency_pd_offline() resets the target through iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer. Freeing the policy data then leaves blkg->use_delay set and blkcg->congestion_count elevated with nothing left that can drop it. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants for as long as the cgroup lives: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear the delay in iolatency_pd_free(). By then bio-held blkg references have drained, or the queue is frozen for policy deactivation, so check_scale_change() cannot re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check. Fixes: d70675121546 ("block: introduce blk-iolatency io controller") Signed-off-by: Usama Arif Acked-by: Tejun Heo Link: https://patch.msgid.link/20260814165712.510132-2-usama.arif@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b399a88eb8b16c5a1a3645fd49ff507fb82b363c Author: Usama Arif Date: Fri Aug 14 09:56:38 2026 -0700 blk-iocost: clear delay state when freeing policy data [ Upstream commit 97cb95d2148835ae86ff916b145aef332d40439d ] iocg_kick_delay() turns sufficiently large debt into an explicit block-cgroup delay with blkcg_set_delay(), setting blkg->use_delay to -1 and incrementing blkcg->congestion_count. Clearing it again depends on iocg_kick_delay() running from the period timer, the waitq timer or the issue path. ioc_pd_free() removes the iocg from active_iocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay. The blkcg stays marked congested for the rest of its life. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear it explicitly, after the list removal and the synchronous hrtimer_cancel() so that neither timer processing nor an I/O path can re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Usama Arif Acked-by: Tejun Heo Link: https://patch.msgid.link/20260814165712.510132-3-usama.arif@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f4ca62414f4fb8af78687aba18f14bb2d1cf3c35 Author: Yu Kuai Date: Mon Jun 8 11:42:43 2026 +0800 blk-cgroup: delay freeing policy data after rcu grace period [ Upstream commit 0af3fedb8c8ed3c07b4f76927bd7fc88f6f82efb ] Currently blkcg_print_blkgs() must hold RCU to iterate blkgs from a blkcg, and prfill() must hold queue_lock to prevent policy data from being freed by policy deactivation. As a consequence, queue_lock has to be nested under RCU from blkcg_print_blkgs(). Delay freeing policy data until after an RCU grace period so prfill() can be protected by RCU alone. Signed-off-by: Yu Kuai Link: https://patch.msgid.link/e20e5d984b41a026d61851966bed35eb094c4bff.1780621988.git.yukuai@fygo.io Signed-off-by: Jens Axboe Stable-dep-of: 97cb95d21488 ("blk-iocost: clear delay state when freeing policy data") Signed-off-by: Sasha Levin commit d4ba9d888ac0a8f12c78071fff73e1205a0b9293 Author: Yiyang Chen Date: Wed Oct 7 09:54:54 2026 -0400 bpf: Check pointer type for all atomic RMW paths [ Upstream commit 4bc49ae344d65cfcef738f281ac575cf73ca2fc5 ] Atomic RMW verification records an instruction pointer type only when the current destination is PTR_TO_ARENA. A second path can therefore reach the same instruction with an ordinary pointer without comparing it against the saved arena type. The post-verification fixup uses the saved type to rewrite the instruction to BPF_PROBE_ATOMIC for every path. Record the actual destination type for all atomic RMW paths so the existing mismatch check rejects incompatible uses of one instruction. Fixes: d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT") Signed-off-by: Yiyang Chen Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260816-bpf-next-038-mixed-atomic-v1-v2-1-4644c1886dbc@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 272c05a51285fe3495ab2f7eb77a48ad831b929f Author: Yunseong Kim Date: Tue Jul 21 02:05:13 2026 +0200 ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user() [ Upstream commit 7405d0ba294306721843bc551611775e6edef516 ] ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC login response with user->passkey_sz = resp->hash_sz; user->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP); if (user->passkey) memcpy(user->passkey, resp->hash, resp->hash_sz); resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login response can set hash_sz well beyond that (up to 65535), so the memcpy() reads past the end of the response object. ipc_validate_msg() does not bound hash_sz, so reject any response whose hash_sz exceeds the on-stack hash[] buffer before allocating and copying. [ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680 [ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611 [ 2030.242296] [ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy) [ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work [ 2030.242763] Call Trace: [ 2030.242769] [ 2030.242776] dump_stack_lvl+0xa2/0xd0 [ 2030.242794] print_address_description+0x77/0x200 [ 2030.242815] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242831] print_report+0x58/0x70 [ 2030.242848] kasan_report+0x117/0x150 [ 2030.242869] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242888] kasan_check_range+0x3c7/0x3f0 [ 2030.242908] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242925] __asan_memcpy+0x29/0x70 [ 2030.242942] ksmbd_alloc_user+0x278/0x680 [ 2030.242960] ksmbd_login_user+0xc3/0x120 [ 2030.242978] ntlm_authenticate+0x5e6/0x1b00 [ 2030.243017] ? __pfx_ntlm_authenticate+0x10/0x10 [ 2030.243035] ? ksmbd_session_lookup+0x188/0x1d0 [ 2030.243054] ? __pfx_ksmbd_session_lookup+0x10/0x10 [ 2030.243090] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0 [ 2030.243126] ? copy_from_kernel_nofault+0x199/0x300 [ 2030.243156] ? __pfx_smb2_sess_setup+0x10/0x10 [ 2030.243173] ? get_smb2_cmd_val+0xe3/0x1c0 [ 2030.243208] handle_ksmbd_work+0x954/0x1280 [ 2030.243230] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 2030.243249] ? process_scheduled_works+0xa07/0x1490 [ 2030.243270] ? process_scheduled_works+0xa07/0x1490 [ 2030.243291] process_scheduled_works+0xa70/0x1490 [ 2030.243320] ? __pfx_process_scheduled_works+0x10/0x10 [ 2030.243340] ? do_raw_spin_lock+0x130/0x300 [ 2030.243358] ? lock_is_held_type+0x7b/0x110 [ 2030.243388] worker_thread+0x932/0xe20 [ 2030.243415] kthread+0x38a/0x470 [ 2030.243431] ? __pfx_worker_thread+0x10/0x10 [ 2030.243451] ? __pfx_kthread+0x10/0x10 [ 2030.243467] ret_from_fork+0x484/0x910 [ 2030.243485] ? __pfx_ret_from_fork+0x10/0x10 [ 2030.243501] ? __switch_to+0xc77/0x12c0 [ 2030.243523] ? __pfx_kthread+0x10/0x10 [ 2030.243540] ret_from_fork_asm+0x1a/0x30 [ 2030.243564] [ 2030.243570] [ 2030.290164] Allocated by task 19279: [ 2030.290911] kasan_save_track+0x3e/0x80 [ 2030.292179] __kasan_kmalloc+0x72/0x90 [ 2030.293217] __kvmalloc_node_noprof+0x3ff/0x6b0 [ 2030.294467] handle_generic_event+0x59b/0x750 [ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340 [ 2030.296553] genl_rcv_msg+0x606/0x7b0 [ 2030.297129] netlink_rcv_skb+0x22b/0x4a0 [ 2030.298500] genl_rcv+0x2d/0x40 [ 2030.299273] netlink_unicast+0x7ba/0x930 [ 2030.300019] netlink_sendmsg+0x8c3/0xb00 [ 2030.301073] __sock_sendmsg+0xec/0x140 [ 2030.301579] __sys_sendto+0x357/0x470 [ 2030.302255] __x64_sys_sendto+0xe3/0x100 [ 2030.303425] do_syscall_64+0x135/0x460 [ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2030.305594] [ 2030.305819] The buggy address belongs to the object at ffff888121bb6640 [ 2030.305819] which belongs to the cache kmalloc-192 of size 192 [ 2030.309595] The buggy address is located 64 bytes inside of [ 2030.309595] allocated 166-byte region [ffff888121bb6640, ffff888121bb66e6) [ 2030.312484] [ 2030.312719] The buggy address belongs to the physical page: [ 2030.314315] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x121bb6 [ 2030.316481] head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 2030.318248] flags: 0x100000000000040(head|node=0|zone=2) [ 2030.319662] page_type: f5(slab) [ 2030.320242] raw: 0100000000000040 ffff8881000424c0 ffffea00047c1510 ffff888100040468 [ 2030.321911] raw: 0000000000000000 0000000000150015 00000000f5000000 0000000000000000 [ 2030.324413] head: 0100000000000040 ffff8881000424c0 ffffea00047c1510 ffff888100040468 [ 2030.326150] head: 0000000000000000 0000000000150015 00000000f5000000 0000000000000000 [ 2030.327960] head: 0100000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff [ 2030.329615] head: ffff888121bb7ab0 0000000000000000 00000000ffffffff 0000000000000000 [ 2030.331861] page dumped because: kasan: bad access detected [ 2030.332946] [ 2030.333502] Memory state around the buggy address: [ 2030.334698] ffff888121bb6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2030.336475] ffff888121bb6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 [ 2030.338143] >ffff888121bb6680: 00 00 00 00 00 00 00 00 00 00 00 00 06 fc fc fc [ 2030.339116] ^ [ 2030.341315] ffff888121bb6700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2030.342801] ffff888121bb6780: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb [ 2030.344643] ================================================================== Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit dc1e34f78dfab755fab9ad820ac5f82348fe1792 Author: Namjae Jeon Date: Tue Jul 28 22:17:14 2026 +0900 ksmbd: serialize oplock close with pending break ownership [ Upstream commit b0148dc5625dbfd50596ac63c7487c12e8a8ab03 ] close may abort an in-flight oplock break while another breaker already holds an opinfo reference. Releasing pending_break wakes that waiter, but without serializing the close transition with bit acquisition it can become a new break owner through the test_and_set_bit() fast path. It can then overwrite OPLOCK_CLOSING with OPLOCK_ACK_WAIT and continue a break for a dying opinfo. Make OPLOCK_CLOSING terminal once the opinfo is removed from the inode list. Serialize that transition, pending_break acquisition, and OPLOCK_ACK_WAIT setup with an opinfo state lock. A breaker which loses the race releases its ownership and returns -ENOENT. Explicitly wake pending_break waiters during close so they can observe the terminal state. Also prevent ACK and timeout paths from replacing OPLOCK_CLOSING with OPLOCK_STATE_NONE. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Co-developed-by: Yunseong Kim Signed-off-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ff6870cf3b7eccc69d03cbb6f23e3995d96e9a8d Author: Ilan Dudnik Date: Sat Aug 1 20:18:48 2026 +0300 ksmbd: defer publishing granted locks to prevent UAF/double-free race [ Upstream commit 29f74f0f2e6df3b393b7b66e810136d0c64e3c59 ] In smb2_lock(), mid-batch granted locks are published to connection-wide (conn->lock_list) and file-wide (fp->lock_list) lists immediately upon vfs_lock_file() success, while also remaining tracked on the stack-local rollback_list. If a subsequent element in the same SMB2_LOCK request array fails validation or execution, the thread jumps to out: and walks rollback_list to undo previously granted locks. However, because the granted lock was already published to conn->lock_list, a concurrent UNLOCK request on the same connection can find the lock object and kfree() it before the rollback loop executes. When the granting thread subsequently walks rollback_list, it dereferences and frees the already-freed ksmbd_lock structure, resulting in a Use-After-Free and Double-Free (on both ksmbd_lock and struct file_lock). Fix this by deferring the publication of granted locks to conn->lock_list and fp->lock_list until after the entire array of lock elements has been processed without error. Mid-batch grants remain tracked exclusively on the request-local rollback_list until the whole batch succeeds, eliminating the race window. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Ilan Dudnik Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 52b91bc5253bb83665f3ea70565d0b2487dae643 Author: Namjae Jeon Date: Wed Jul 29 21:25:35 2026 +0900 ksmbd: safely discard unregistered deferred locks [ Upstream commit 054bcca4cd9f00719b01f7108b51a2168fb94f15 ] When vfs_lock_file() defers a lock, smb2_lock() puts its ksmbd_lock on rollback_list before allocating and registering the asynchronous work. If either operation fails, rollback assumes that smb_lock->conn is initialized and dereferences NULL. The deferred file_lock also remains linked into the VFS blocked-lock state while it is freed. Keep the lock off rollback_list until async setup succeeds. On setup failures, explicitly unblock and wake the deferred lock before freeing it and its ksmbd wrapper. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f77d2accafca529e0ea3f979eb6e6cf1dac05c90 Author: Namjae Jeon Date: Fri Aug 14 11:18:38 2026 +0900 ksmbd: detach blocked lock requests before freeing [ Upstream commit 215e8816b1ac25176d911abb8704390413ccee4b ] A file_lock retained by ksmbd for byte-range lock bookkeeping can still be part of the VFS blocked-request graph. In particular, the VFS can chain a new waiter below an already blocked request through flc_blocked_requests. The ksmbd_file reference count does not cover that graph. Both __ksmbd_close_fd() and the cross-request unlock path free these retained file_lock objects directly. If a dependent waiter is still attached, locks_release_private() hits BUG_ON(!list_empty(&flc->flc_blocked_requests)). The same lifetime mismatch can leave a freed ksmbd_lock reachable through its request-local llist. Detach the file_lock from the blocked-request graph before freeing it in the close, cross-request unlock, and rollback paths. locks_delete_block() also wakes requests chained below the object. Remove llist when a completed lock is published so a globally visible ksmbd_lock no longer points into the submitting worker's stack. Fixes: d63528eb0d43 ("ksmbd: free ksmbd_lock when file is closed") Reported-by: Kyenghwan Hwang Tested-by: Kyenghwan Hwang Tested-by: ChenXiaoSong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1ff0e41afbe73240a7d7b96d4e8e86d0aaf0fe0b Author: Namjae Jeon Date: Thu Aug 13 09:01:00 2026 +0900 ksmbd: scope session state changes to bound connections [ Upstream commit c50e628122aed077695669e25b842e778511a43d ] ksmbd_all_conn_set_status() treats every connection whose transient binding flag is set as belonging to the target SessionId. A logoff or session replacement can consequently move an unrelated connection to NEED_RECONNECT or NEED_SETUP. Pass the target session itself and select connections using either the connection-local session xarray or the session's permanent channel list. Use the same association test while waiting for requests to drain. Serialize session-wide status changes under request_lock and do not overwrite EXITING or RELEASING. Protect the shutdown transition with the same lock so a concurrent session update cannot revive a closing connection. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Fixes: abcc506a9a71 ("ksmbd: fix racy issue from smb2 close and logoff with multichannel") Fixes: c444139cb747 ("ksmbd: rewrite stop_sessions() with restartable iteration") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d39da3ff8d39c31761bf1698bc02a5a206722136 Author: Petr Oros Date: Thu Aug 13 16:08:17 2026 +0200 dpll: fix NULL deref in dpll_device_ops() during teardown race [ Upstream commit 33f016b23a219fe034213849b51436b8e79df251 ] When the last owner of a dpll device unregisters while a foreign driver still holds a pin on it via dpll_pin_on_pin_register(), the dpll object stays alive with an empty registration list. A pin notification queued before the unregister (e.g. ice reacting to zl3073x_i2c removal) then walks pin->dpll_refs into dpll_device_ops(), which trips the WARN_ON and dereferences the missing registration. dpll_lock cannot help because the notification work was queued before the unregistering driver took the lock. Treat the empty registration list as a legitimate transient state. Make dpll_priv() and dpll_device_ops() return NULL in that case and make every pin netlink path that resolves a device from a pin skip such dplls. dpll_cmd_pin_get_one() picks a ref with a live registration and returns -ENODEV when there is none, the pin dumpit skips such a pin instead of aborting the dump, dpll_msg_add_pin_dplls() and the frequency, esync, reference sync and phase adjust set paths skip dead refs, and dpll_pin_parent_device_set() validates the parent with dpll_device_get_by_id(). dpll_pin_register() is the last caller that dereferenced the device ops without a check, so move its frequency monitor validation under dpll_lock and tolerate a missing registration there as well. The empty registration list is equivalent to a cleared DPLL_REGISTERED mark, both transitions happen under dpll_lock in dpll_device_register() and dpll_device_unregister(). A pin notification for a pin whose dplls are all gone is now dropped with -ENODEV instead of crashing, all callers in the core ignore that return value. WARNING: drivers/dpll/dpll_core.c:1092 at dpll_device_ops+0x24/0x40, CPU#83: kworker/u576:3/23471 Modules linked in: ... ice ... zl3073x_i2c(-) ... zl3073x ... Workqueue: ice_dpll_wq ice_dpll_pin_notify_work [ice] RIP: 0010:dpll_device_ops+0x24/0x40 Call Trace: dpll_cmd_pin_get_one+0x336/0x520 dpll_pin_event_send+0x82/0x140 dpll_pin_on_pin_unregister+0xbb/0x160 ice_dpll_pin_notify_work+0x1bc/0x1f0 [ice] process_one_work+0x19e/0x370 worker_thread+0x1a6/0x310 kthread+0xe4/0x120 ret_from_fork+0x1a1/0x270 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Petr Oros Tested-by: Ivan Vecera Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260813140817.1051388-1-poros@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5235abdb760bbd7a6fcecf1890b5160b7a75a9ce Author: Anton Protopopov Date: Mon Aug 10 12:07:25 2026 +0000 virtio_net: Fix resize of the RX ring [ Upstream commit d09c98a6da215bce2173a292e4b95c8de6ea5d51 ] When a AF_XDP socket is attached, the virtnet_rx_resize should resize the rq->xsk_buffs XSK buffer array. Otherwise, when the size grows, the virtnet_rx_resume() causes a write past the end of the array. This is easily reproducable with ethtool -G ens3 rx 32 ./xdpsock -i eth0 -q 0 -r -z & ethtool -G eth0 rx 256 Fixes: e9f3962441c0 ("virtio_net: xsk: rx: support fill with xsk buffer") Signed-off-by: Anton Protopopov Link: https://patch.msgid.link/20260810120728.47445-1-a.s.protopopov@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0887d41abf76638942688cb0c0ff8087f52e2b33 Author: Sascha Bischoff Date: Tue Aug 11 15:27:00 2026 +0000 irqchip/gic-v5: Clear per-CPU IRS data on teardown [ Upstream commit 3dfc0ab5fefd052c6028c4632b1fad8bdaf7967e ] IRS affinity setup publishes an IRS pointer and IAFFID state in the per-CPU data before the remaining IRS initialization can fail. The error path then frees the IRS data without clearing that published state, leaving CPUs associated with freed memory. On initialization failure and normal IRS teardown, clear the per-CPU IRS association by removing the stale pointer to irs_data. Also invalidate the per-CPU IAFFID state for any CPUs that were tied to the IRS before it was freed. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Lorenzo Pieralisi Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=2 Link: https://patch.msgid.link/20260811152630.942023-2-sascha.bischoff@arm.com Signed-off-by: Sasha Levin commit f57b0fd1c62e1be274ee154ab7fb8ac4481b7f89 Author: Eric Dumazet Date: Tue Aug 18 17:27:55 2026 +0000 ip6mr: do not clone dst in ip6mr_cache_report() [ Upstream commit 235b42b5860189eb8c27c36435ad932cae65a734 ] IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mr_cache_unresolved() places the skb onto the unresolved queue, escaping the receive-side RCU grace period. If the underlying route is deleted and freed, and the MFC queue is later resolved with a wrong parent interface, ip6_mr_forward() invokes ip6mr_cache_report(..., MRT6MSG_WRONGMIF), which executes dst_clone(skb_dst(pkt)) on the freed dst entry, triggering a slab use-after-free. Report packets queued to mroute6_sk (a raw socket) and netlink notifications do not require an attached dst entry. Fix this by: 1. Removing dst_clone() in ip6mr_cache_report() and ensuring report skbs do not hold a dst. 2. Dropping skb_dst before queuing unresolved skbs in ip6mr_cache_unresolved(), matching the fact that multicast forwarding resolves outgoing routes anew via ip6_route_output(). Fixes: 67f415dd2906 ("ipv6: convert rx data path to not take refcnt on dst") Reported-by: Zero Day Initiative Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260818172755.4083692-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 884cbf15ccd3980bcc9583073045f91798a86d4e Author: Nikolay Aleksandrov Date: Tue Aug 18 18:07:55 2026 +0300 net: bridge: arp/nd proxy: fix reading neigh ha [ Upstream commit 57549ab9079122991dfa0f8248ca00e101e8e69b ] Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address. Fixes: 057658cb33fb ("bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports") Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260818150756.890025-2-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f43ef9a3f9c121472a0754c9e9bff13317ace0f7 Author: Nikolay Aleksandrov Date: Tue Aug 18 18:07:56 2026 +0300 vxlan: fix reading neigh ha [ Upstream commit b824059a673b2283e78c7aae2c7d257aad7f0e1d ] Currently arp/neigh_reduce read neigh ha directly which can lead to partial reads while the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address similar to route_shortcircuit which already does the right thing. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260818150756.890025-3-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4d23937e1c41995c2f54af26c89b5e48a41c299 Author: Jérémy Jean Date: Wed Oct 7 07:41:07 2026 -0400 NFSv4.1: zero referring call lists before decoding [ Upstream commit 8fa4804fe62ca4155a2d8fc2789d630376cbf2fc ] decode_cb_sequence_args() allocates csa_rclists with kmalloc_objs(), so each referring_call_list starts uninitialized. decode_rc_list() assigns rcl_refcalls only when rcl_nrefcalls is nonzero. A valid list with zero referring calls therefore leaves the pointer uninitialized, and nfs4_callback_sequence() later passes stale slab contents to kfree(). Allocate csa_rclists with kzalloc_objs() so every rcl_refcalls member is NULL from the beginning, including valid empty referring call lists. Fixes: 4aece6a19cf7 ("nfs41: cb_sequence xdr implementation") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 68fb30607169c92de57c5c82b6af8a733af1cc09 Author: Jamal Hadi Salim Date: Wed Aug 19 10:37:33 2026 -0400 net/sched: account classifier filter allocations to memcg [ Upstream commit 1beb81947eb486716af80db7a584f9e9fef7e003 ] Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted. Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw, cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which allocates the same struct tc_u_knode + sel.keys on every replace of an existing knode and was missed by the create-path-only conversion. Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern. Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used), CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo ingress ... ...) while watching a memcg-limited cgroup: system slab grows far faster than memory.current, pinning kernel memory outside memcg charging. Fixes: 0da974f4f303 ("[NET]: Conversions from kmalloc+memset to k(z|c)alloc.") Reported-by: vega@nebusec.ai Signed-off-by: Jamal Hadi Salim Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260819143733.57538-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ca1df82d9248fc0b5ff17d45607484f18e5d60b Author: Bernd Schubert Date: Fri Aug 21 18:19:09 2026 +0200 fuse: Fix the condition to enable over-io-uring [ Upstream commit 1f59015e958174e89be58cc8db16d70a60d17255 ] The existing condition in fuse_uring_cmd() is there only to avoid disabling io-uring for connections that already run with it, missing was a condition to refuse any IORING_OP_URING_CMD if the connection/channel didn't get enabled because of missing FUSE_INIT reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in fuse_uring_ready() doesn't work and IO could already be going on and cause deadlock states (at a minimum one between fch->bg_lock and queue->lock). The change itself is trivial, but brings behavior change, FUSE_OVER_IO_URING has to be set in the FUSE_INIT_REPLY by fuse servers to accept any IORING_OP_URING_CMD. Libfuse does that and the only non-libfuse implementation I found (fractal-fuse) also does it. Qemu patches for fuse-io-uring are not merged yet, as far as I know. Moved up is the smp_load_acquire(&fch->initialized) check, as a fuse-server implementation might try to setup io-uring before FUSE_INIT is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN. Also fixed is a stale comment that explains the handling of the FUSE_OVER_IO_URING flag in early RFC versions. If there should be a report from any library or application we probably need to revert this commit. Fixes: 3393ff964e0f ("fuse: block request allocation until io-uring init is complete") Signed-off-by: Bernd Schubert Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 8460dc49c9756a1e9288218060b4d41e1b704905 Author: Pauli Virtanen Date: Sun Aug 9 20:42:41 2026 +0300 Bluetooth: L2CAP: access chan->conn safely in get/setsockopt [ Upstream commit ca2c4c26498643f421d35ffe258fafbd3ed461c3 ] Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted. In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev. Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields. Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") Reported-by: syzbot+b106284c2a0b7bc80cf9@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=b106284c2a0b7bc80cf9 Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8a8585e421d06f878b33ef79f82cace0d485e3d8 Author: Radek Podgorny Date: Mon Aug 24 13:00:20 2026 +0200 Bluetooth: do not leak an hci_conn when a second LE connect is rejected [ Upstream commit 7e1e4047200fd7519f9bdfe8a001437715e618b4 ] create_le_conn_complete() decides whether the failed connection is still pending by comparing it against hci_lookup_le_connect(), which returns the first LE connection in BT_CONNECT. That is the same connection only while at most one is pending. Two can be pending. Connections created on the passive scan path sit in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to hci_lookup_le_connect() until hci_le_create_conn_sync() clears the flag when their command is issued, so the -EBUSY guard in hci_connect_le() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BT_CONNECT at once, the lookup may return one connection while create_le_conn_complete() is reporting the failure of the other; the early exit then drops the error and hci_conn_failed() never runs on the connection that failed. The controller also rejects a second HCI_OP_LE_CREATE_CONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bt_to_errno() maps to the -EPROTO (-71) in the log below. The leaked connection stays in BT_CONNECT forever, and because hci_connect_le() refuses to dial while hci_lookup_le_connect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all. Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BT_CONNECT; both handles are UNSET ones, allocated from the ida above HCI_CONN_HANDLE_MAX): Bluetooth: hci1: Opcode 0x2013 failed: -71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL A btmon capture across the next ten minutes of connect attempts contains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through. Ask about the connection itself instead of about the device. Fixes: c9f73a2178c1 ("Bluetooth: hci_conn: Fix hci_connect_le_sync") Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7b3e08eea1e8cae37e84540c5cb4aee4887e46ac Author: Long Li Date: Fri Aug 21 11:37:36 2026 -0700 net: mana: Cap MSI-X vectors to the device MSI-X table size [ Upstream commit 2c7493f980140a5c40eb4f98f97c557193a2c330 ] mana_gd_query_max_resources() sizes gc->num_msix_usable from resp.max_msix and the CPU count, but never from the device MSI-X table. On a 1792 vCPU M-series VM that yields 1793 while the table has 1024 entries, and mana_gd_setup_remaining_irqs() then walks indices 1..1792, running off the end of the region mapped by msix_map_region(): BUG: unable to handle page fault for address: ff8e347f8b99800c RIP: 0010:msix_prepare_msi_desc+0x7a/0x90 RAX: 0000000000004000 RBX: ff4330cb164ea780 RCX: ff8e347f8b998000 Call Trace: __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 RAX is index 1024 * PCI_MSIX_ENTRY_SIZE, one entry past the table. msi_insert_desc() does range check the index, but only against the MSI domain hwsize, which matches the table only for devices on an MSI parent domain. With a global PCI/MSI domain hwsize is MSI_XA_DOMAIN_SIZE, so nothing bounds the request. Cap num_msix_usable with pci_msix_vec_count(). Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically") Signed-off-by: Long Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821183736.733296-1-longli@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c08314f91782983d67af0807ed1360e404ac4a8b Author: Sai Krishna Date: Fri Aug 21 15:53:37 2026 +0530 octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init() [ Upstream commit 3b11a77f69980932c3924054d66e565c9a135747 ] rvu_mbox_init() is called separately for AF-PF mailboxes during probe and for AF-VF mailboxes when SR-IOV is enabled. Each call used to allocate a new ng_rvu object, leaking the first allocation when the pointer was overwritten on the second call. Sharing one ng_rvu across both paths exposed several teardown bugs: the error path freed all cn20k mailbox DMA and kfree()d ng_rvu even when only the failing init type should be unwound, leaving live AF-PF mailbox memory in use after an AF-VF init failure. mutex_init() was also re-run on the AF-VF path while AF-PF mailbox handlers could still hold rvu->mbox_lock. Probe and SR-IOV failure paths did not release cn20k mailbox DMA either, since cleanup only happened in rvu_remove(). Allocate ng_rvu once with devm_kzalloc(), initialize mbox_lock in the same block, unwind only the mailbox memory for the failing init type, and free cn20k mailbox DMA from the probe and pci_enable_sriov() error paths. Fixes: e53ee4acb220 ("octeontx2-af: CN20k basic mbox operations and structures") Signed-off-by: Sai Krishna Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821102337.2989169-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6b56b8d549a043b6c8ff616db8748263eae05ae Author: Pablo Neira Ayuso Date: Wed Aug 19 13:42:36 2026 +0200 netfilter: nf_tables: skip double clone set expressions on element insert [ Upstream commit 43559058d21e0493aa220ac167e0279334dea5f9 ] Both the dynset and newsetelem path clone the existing set expressions when setting set element expressions if no override expressions are provided. This results in a double clone, once to clone the template set expressions then another clone on the new element. Add a flag to annotate if userspace provides a override expression (ie. expression of the same type of the set but different configuration), otherwise borrow the existing expression from the set. Add conditionals to release expression iif they represent an override. Use this new override_exprs flag to dump the dynset expression override to userspace. This simplifies the existing logic and it also fixes a bug with the connlimit expression which results in a module refcount imbalance WARNING splat when resorting on the default set expressions. Fixes: 65038428b2c6 ("netfilter: nf_tables: allow to specify stateful expression in set definition") Fixes: fca05d4d61e6 ("netfilter: nft_dynset: honor stateful expressions in set definition") Reported-by: Xingyuan Mo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ef4dee4640c6adc3051401399b0788135e77d50b Author: Sean Christopherson Date: Thu Jul 9 13:49:40 2026 -0700 KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped [ Upstream commit d1a3c216233413f57f5341a9b878b7e2dde7e785 ] Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99a64d198000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 13eb001067 P4D 13eb001067 PUD 78d1d1063 PMD 1184e0063 PTE 800000078d198163 SEV-SNP: PFN 0x78d198, RMP entry: [0x6030000000144001 - 0x000000000000000f] Oops: Oops: 0003 [#1] SMP CPU: 3 UID: 0 PID: 31407 Comm: highlanderd_hea Tainted: G U W O Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:prep_new_page+0x67/0x220 Call Trace: get_page_from_freelist+0x1c40/0x1c70 __alloc_frozen_pages_noprof+0xca/0x1f0 alloc_pages_mpol+0x10b/0x1b0 alloc_pages_noprof+0x81/0x90 pte_alloc_one+0x1b/0xd0 do_pte_missing+0xdf/0x1020 handle_mm_fault+0x7c7/0xb20 do_user_addr_fault+0x268/0x6b0 exc_page_fault+0x67/0xa0 asm_exc_page_fault+0x26/0x30 RIP: 0033:0x4a6b1e gsmi: Log Shutdown Reason 0x03 CR2: ffff99a64d198000 ---[ end trace 0000000000000000 ]--- RIP: 0010:prep_new_page+0x67/0x220 Drop the pseudo-TODO comment about needing to pin the page if guest_memfd every supports migration, as integrating with invalidations events means KVM will Just Work if/when page migration is ever supported (assuming SNP hardware supports migrating VMSA pages). Note #3, invalidate() and invalidate_range() have _completely_ different semantics; the new invalidate_range() is a true invalidation, whereas the existing invalidate() is really a "make shared" operation. Ignore the confusing naming and poor Kconfig bundling for the moment to minimize the delta for LTS kernels, the mess will be cleaned up shortly. Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Cc: Tom Lendacky Cc: Michael Roth Cc: Jörg Rödel Cc: Fuad Tabba Cc: Ackerley Tng Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-11-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 506f03b5f869cbae50d31b50d80d4a5735d47f94 Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Validate MSI data before routing it to EIOINTC [ Upstream commit 501514d6ebd2111c353a1296f25dbe22fbd64657 ] pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as the irq number. The MSI data comes from userspace, that either via a KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked against EIOINTC_IRQS. eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the 256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and the per-cpu coreisr/sw_coreisr bitmaps with it. Therefore a data value >= 256 reads and writes memory past the end of those arrays, i.e. any process holding a VM fd can corrupt kernel memory beyond the allocation of loongarch_eiointc. Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC path is unaffected as it decodes the vector from the address and masks it. Cc: stable@vger.kernel.org Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@smtp.kernel.org/ Reviewed-by: Tao Cui Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 34a2a7134fd66822858b54e285f225bd4c1889bf Author: Bibo Mao Date: Thu Nov 27 11:00:18 2025 +0800 LoongArch: KVM: Get VM PMU capability from HW GCFG register [ Upstream commit 74087611f0ba7b336dcdde855ffca7d15b2ebe0f ] Now VM PMU capability comes from host PMU capability directly, instead bit 23 of HW GCFG CSR register also show PMU capability for VM. It will be better if it comes from HW GCFG CSR register rather than just host PMU capability, especially when LVZ feature is emulated in TCG mode, in which case without PMU capability. Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Stable-dep-of: 501514d6ebd2 ("LoongArch: KVM: Validate MSI data before routing it to EIOINTC") Signed-off-by: Sasha Levin commit 56c2c5ad35614ca5ae23838d6af5d7f59e3124dc Author: Jackson Lee Date: Fri Jun 26 10:22:32 2026 +0900 media: chips-media: wave5: Resume device before setting EOS flag [ Upstream commit a52e6f7923c17a672135b485ffd96fbd72f46267 ] Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run(). Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c26cbd5c33cd72daa03079235de60688a3c97c52 Author: Jesse Zhang Date: Thu Aug 13 12:28:04 2026 +0800 drm/amdgpu: force complete the KIQ ring fences on reset [ Upstream commit fd65d1742992361fc2201ecb4e43411e6e417fcb ] Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back. Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq. Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Suggested-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7d722821e2f626c4e34c8510f0ce1d6f10c77a3b Author: Jesse Zhang Date: Thu Aug 13 12:27:53 2026 +0800 drm/amdgpu: force complete the MES ring fences on reset [ Upstream commit 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5 ] The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet. When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset: amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block failed -110 amdgpu: GPU reset end with ret = -110 Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq. v2: cover all XCCs (one scheduler ring each), not just mes.ring[0]. Cc: stable@vger.kernel.org Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ef073edd7cfd31aeb90eeab23273102c601f4d8e Author: Longlong Xia Date: Tue Aug 4 14:59:18 2026 +0800 zram: fix out-of-bounds access in writeback_store() [ Upstream commit 894913e2d35c46ff19a77530907771ae57862b96 ] Patch series "zram: fix stale scan bounds after reinitialization". Both writeback_store() and read_block_state() derive their table scan bounds from zram->disksize before acquiring dev_lock. If the device is reset and reinitialized with a smaller disksize between that read and lock acquisition, the bound can describe the old table while the scan operates on the new one. This can lead to out-of-bounds slot accesses. Move both bound calculations under dev_lock so each bound remains consistent with the table throughout its scan. Keep the fixes separate because the affected interfaces originate from different commits and can be backported independently. This patch (of 2): writeback_store() calculates the table scan bounds before taking dev_lock. A reset followed by reconfiguration with a smaller disksize can therefore replace zram->table while writeback_store() is waiting for the lock. Once it acquires the lock, it sees an initialized device but scans the new table using the old upper bound, resulting in an out-of-bounds access. Calculate the number of pages while holding dev_lock so the scan bound matches the table protected by the lock. Link: https://lore.kernel.org/20260804065919.3970386-1-xialonglong2025@163.com Link: https://lore.kernel.org/20260804065919.3970386-2-xialonglong2025@163.com Fixes: a939888ec38b ("zram: support idle/huge page writeback") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Sergey Senozhatsky Cc: Jens Axboe Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 836ce2b99bcce6d68c58edd04efbc5cd1fd581af Author: Jeff Layton Date: Thu Jun 11 16:00:59 2026 -0400 lockd, nfsd: RCU-protect nlmsvc_ops dispatch [ Upstream commit 641e5e20852359b8c31149be4598884e30652f60 ] nlmsvc_ops is published by nfsd_lockd_init() and cleared by nfsd_lockd_shutdown() with plain stores, while lockd dereferences it unguarded from dispatch sites in fs/lockd/svcsubs.c. The pointer targets nfsd's .rodata and the fopen/fclose callbacks live in nfsd's .text, so a stale load after rmmod nfsd results in either a NULL deref or a module-text use-after-free. Declare nlmsvc_ops as __rcu, publish via rcu_assign_pointer(), clear via RCU_INIT_POINTER() + synchronize_rcu(). Add a struct module *owner field to nlmsvc_binding and pin the module across indirect calls with try_module_get/module_put. When the binding is torn down, fall back to fput() to avoid leaking struct file references. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-16-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit df5500ab85df661d9e4439e4c456787181fbd5ff Author: Jeff Layton Date: Thu Jun 11 16:01:02 2026 -0400 nfsd: restore rq_status_counter to even on all nfsd_dispatch() exit paths [ Upstream commit f6045886fe3f14f269f683d64021b004a50d0efa ] nfsd_dispatch() sets rq_status_counter to an odd value once a request has been decoded, and back to an even value once it has been fully processed, forming a seq-lock like protocol with the lockless reader in nfsd_nl_rpc_status_get_dumpit(). Only the fully successful path restored the counter to even. The cache-hit (RC_REPLY), drop (RC_DROPIT / RQ_DROPME) and encode-error paths all return after the odd-valued store without ever bringing the counter back to even. Once one of those paths is taken, rq_status_counter is left odd: the next request's decode ORs in 1 (still odd) and only a subsequent successful encode restores even. While stuck odd, the dumpit reader treats the rqstp fields as stable and its retry check compares against the same unchanging odd value, so it never detects concurrent mutation. This exposes actively mutating fields (e.g. args->ops / args->opcnt during compound decode and release) to the lockless reader, which can read past the end of the 8-element inline ops array. Add a helper that advances the counter to the next even value and call it on every return path that follows the odd-valued store. The decode-error path is left untouched as it is reached before the counter is set odd. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-19-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 9646dfee880730aae4b379a4b8ee6c88ac735acd Author: Xiubo Li Date: Tue Jul 14 16:13:44 2026 +0800 ceph: fix UAF in check_new_map() on session freed during unlock [ Upstream commit ee611a7509554c4ca1f54f6aefe592fb1df7ea70 ] check_new_map() iterates mdsc->sessions[] and for each active session drops mdsc->mutex to perform per-session operations. The forced-close path (rank removed from map) correctly takes a reference on s via ceph_get_mds_session() before releasing mdsc->mutex, but three other paths do not: Path A (address changed): mutex_unlock → mutex_lock(&s->s_mutex) Path B (reconnect): mutex_unlock → send_mds_reconnect(mdsc, s) Path C (active transition): mutex_unlock → mutex_lock(&s->s_mutex) Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call __unregister_session() which drops the last reference on s, and free it. The original thread then accesses freed memory via s->s_mutex. Fix by adding ceph_get_mds_session(s) before each mutex_unlock and ceph_put_mds_session(s) after the corresponding mutex_lock, matching the pattern already used in the forced-close path. Race timeline (Path A): Thread A (check_new_map) Thread B (another map update holds mdsc->mutex or session teardown) -------------------------- -------------------------- s = mdsc->sessions[i] (refcount == 1, held only by sessions[] array) mutex_unlock(&mdsc->mutex) ---> acquires mdsc->mutex __unregister_session(mdsc, s) sessions[i] = NULL ceph_put_mds_session(s) refcount: 1 -> 0 kfree(s) <--- freed! mutex_lock(&s->s_mutex) UAF on freed s->s_mutex Cc: stable@vger.kernel.org Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit e1f692b6da3e632a25d0b3a99f833bb609bae1a3 Author: Frank Sorenson Date: Thu Aug 20 16:13:10 2026 -0500 cifs: call pagecache_isize_extended() in cifs_setsize() when extending [ Upstream commit c510edb9734af1c274d18f4f31a471a166bbc7e8 ] cifs_setsize() calls truncate_pagecache() but skips pagecache_isize_extended() on extension. truncate_setsize() shows the correct pattern: i_size_write(inode, newsize); if (newsize > oldsize) pagecache_isize_extended(inode, oldsize, newsize); truncate_pagecache(inode, newsize); pagecache_isize_extended() zeroes the tail of the page straddling old EOF. Without it, dirty bytes in that region can be written back to the server, exposing stale data in the newly extended range. Cc: stable@vger.kernel.org Cc: David Howells Signed-off-by: Frank Sorenson Acked-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 5481766125041e71662f2e32ee0e91ad5f4d07f4 Author: Jan Kara Date: Mon Jul 27 12:49:24 2026 +0200 ext2: Fix lost inode updates for IS_SYNC inodes [ Upstream commit 356984d1a5c32e94810cbb6c8dc7d8ff2d4d919a ] ext2_setsize() and ext2_xattr_set2() had a construct like: if (IS_SYNC(inode)) { sync_inode_metadata(inode, 1); } else { mark_inode_dirty(inode); } which leads to lost inode updates for IS_SYNC inodes because sync_inode_metadata() does anything only if the inode is already dirty and hence inode updates may be simply lost. Fix the problem by unconditionally marking the inode dirty and *then* call sync_inode_metadata(). CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260727104923.3828017-26-jack@suse.cz Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0692a8fdf0222af130c8ea97426f1c3bf3814905 Author: Pratyush Yadav (Google) Date: Mon Jul 27 17:02:39 2026 +0200 kho: fix size calculation in kho_preserved_memory_reserve() [ Upstream commit 3a0b8fa2eb36afc88b62a95f33f0c77c71fa5ded ] kho_preserved_memory_reserve() calculates the size of a preservation by doing 1 << (order + PAGE_SHIFT). Since the '1' is a 32-bit integer, it can only be shifted by 31. That is, it will only work for preservations up to 2 GiB. Larger preservations will trigger undefined behaviour. While preservations larger than 2 GiB can't be obtained via folios currently, they can be obtained via kho_preserve_pages(). For example, memblock reserve_mem uses kho_preserve_pages(). Reservations larger than 2 GiB are valid and will trigger this bug if properly aligned. Fix it by using 1UL for shifting. Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260727150240.889555-1-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 996dd15f60121bdd7896b4554458f8806d608063 Author: Chuck Lever Date: Sat May 23 12:52:37 2026 -0400 SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2 [ Upstream commit b94f6719dcd9f7a609bc5f459f85795900e77d25 ] gss_krb5_verify_mic_v2() reads the token ID at ptr[0..1], the flags byte at ptr[2], and padding at ptr[3..7], then passes ptr + GSS_KRB5_TOK_HDR_LEN and cksum_len to gss_krb5_mic_build_sg(). None of these accesses check read_token->len first. The minimum safe token size is GSS_KRB5_TOK_HDR_LEN (16) plus ctx->krb5e->cksum_len (12-24, depending on the enctype). All callers accept shorter tokens from the wire: - gss_unwrap_resp_integ() enforces only an upper bound (offset + len <= rcv_buf->len) before allocating mic.data = kmalloc(len) and passing it to gss_verify_mic(). A malicious NFS server can therefore supply a short checksum opaque, producing a small slab allocation that the Kerberos MIC verifier reads past. - gss_validate() enforces only len <= RPC_MAX_AUTH_SIZE (400) before passing the wire-supplied length to gss_validate_seqno_mic(), which constructs a mic xdr_netobj and calls gss_verify_mic(). - svcauth_gss_verify_header() enforces only checksum.len >= XDR_UNIT (4 bytes) before dispatching to gss_verify_mic(). - svcauth_gss_unwrap_integ() checks only that the checksum fits in gsd->gsd_scratch. Add a length guard at the top of gss_krb5_verify_mic_v2(), before any ptr[] access or scatterlist construction. Well-formed MIC tokens from gss_krb5_get_mic_v2() already have exactly GSS_KRB5_TOK_HDR_LEN + cksum_len bytes, so valid traffic is unaffected. Reported-by: Chris Mason Fixes: de9c17eb4a91 ("gss_krb5: add support for new token formats in rfc4121") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260523165237.510204-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5909f8f04e9b72e19ee4c7d8d960aaf18a956d0f Author: Chuck Lever Date: Mon Apr 27 09:50:54 2026 -0400 SUNRPC: Switch MIC token verification to crypto/krb5 [ Upstream commit d4f6bd01c5bf7afbf4a3d07f2229e06c2236e8ed ] gss_krb5_verify_mic_v2() currently recomputes a checksum using gss_krb5_checksum() and then compares it against the received checksum with memcmp(). Replace this with a call to crypto_krb5_verify_mic(), which performs the hash, comparison, and offset/length adjustment in a single operation through the crypto/krb5 library. The scatterlist layout required by RFC 4121 Section 4.2.4 is constructed via gss_krb5_mic_build_sg(), the shared helper introduced in the preceding commit. The received checksum occupies the first scatterlist entry, pointing directly into the token buffer. The errno result from crypto_krb5_verify_mic() is mapped to a GSS major status code via gss_krb5_errno_to_status(), which returns GSS_S_BAD_SIG for -EBADMSG (checksum mismatch). Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit ffb0423b4f4b07640bb72d354d70b81350bbd652 Author: Chuck Lever Date: Mon Apr 27 09:50:53 2026 -0400 SUNRPC: Switch MIC token generation to crypto/krb5 [ Upstream commit a9b9eb085884cd50de41b8ecb8d0fb9d3268cdfb ] gss_krb5_get_mic_v2() currently computes the MIC checksum by driving a crypto_ahash directly, calling gss_krb5_checksum() with the message body and GSS token header. Replace this with a call to crypto_krb5_get_mic(), which performs the same keyed hash operation through the crypto/krb5 library. RFC 4121 Section 4.2.4 specifies that the checksum covers the message body followed by the token header. Because the crypto/krb5 metadata parameter is hashed before the data, the GSS header cannot be passed as metadata. Instead, the header is appended to the scatterlist after the body data, producing the correct hash input ordering without using the metadata parameter. The scatterlist layout is: [checksum_output | message_body | gss_header] The first scatterlist entry points directly into the token buffer, so the checksum is written in place. A shared helper, gss_krb5_mic_build_sg(), is introduced in gss_krb5_crypto.c to construct this scatterlist layout. The helper handles overflow allocation and scatterlist chaining for large xdr_buf page arrays. It is reused by the verify_mic counterpart in the following commit. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit 1e9125bb7948c66bdfab90200675e06ab05e28dc Author: Chuck Lever Date: Mon Apr 27 09:50:51 2026 -0400 SUNRPC: Switch wrap token decryption to crypto/krb5 [ Upstream commit 598de25deaffb80758ad8bdce5b4bacbbea59582 ] Replace the per-enctype .decrypt callbacks (gss_krb5_aes_decrypt and krb5_etm_decrypt) with a single gss_krb5_aead_decrypt() wrapper that delegates to crypto_krb5_decrypt(). The new wrapper builds a scatterlist covering the secured region (confounder through checksum), passes it to the AEAD decrypt operation, and derives the confounder and checksum lengths from the data offset and length that crypto_krb5_decrypt() reports. The caller's token header verification and buffer adjustment logic is unchanged. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit 5ec781a29eed1104ec24f2970b11f907931f0656 Author: Chuck Lever Date: Mon Apr 27 09:50:50 2026 -0400 SUNRPC: Switch wrap token encryption to crypto/krb5 [ Upstream commit f1965a3bcb1dc9b3491f750abc0f30a595c3de9f ] Replace the per-enctype .encrypt callbacks (gss_krb5_aes_encrypt and krb5_etm_encrypt) with a single gss_krb5_aead_encrypt() wrapper that delegates to crypto_krb5_encrypt(). The xdr_buf setup -- GSS header insertion, confounder space allocation, and token header copy -- remains unchanged. The difference is that the CBC-CTS encryption and HMAC computation are now a single AEAD operation through the crypto/krb5 library. Both the MtE construction (RFC 3962) and the EtM construction (RFC 8009) are handled transparently by the AEAD transform. The plaintext page data must be copied from the page cache pages to the scratch output pages before building the scatterlist, since the AEAD operates in-place rather than using separate input and output scatterlists. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit 6b4d0c9cf2b10cebadd6f568251c954e91588510 Author: Chuck Lever Date: Mon Apr 27 09:50:49 2026 -0400 SUNRPC: Prepare crypto/krb5 encryption and checksum handles [ Upstream commit 25ccbefc9fd6f62acbf2f3d8eb9e2b3950e5fe28 ] Allocate crypto_aead handles for encryption (one per direction) and crypto_shash handles for checksumming (one per direction) using the crypto/krb5 library's key preparation functions. These four handles derive their subkeys from the session key and the RFC 4121 usage numbers and are ready for use in encrypt, decrypt, get_mic, and verify_mic operations. The existing crypto_sync_skcipher and crypto_ahash handles remain in place for now; subsequent patches switch the per-message operations to the new handles and then remove the old ones. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit 5cf04fdbbf30e5b38b47f08b2cd9f5059fa429db Author: Chuck Lever Date: Mon Apr 27 09:50:48 2026 -0400 SUNRPC: Add errno-to-GSS status conversion helper [ Upstream commit 6e5e0c58dbd059eef27f01805c032b8fa3cd5eb1 ] The crypto/krb5 library returns standard negative errno values, but the GSS mechanism layer reports results as GSS_S_* major status codes. A translation is needed at each call site that will be switched to the new library. Rather than open-coding the mapping in every wrapper, provide a single helper function. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit 08efba8d6256053ac1f2fabd2b7b2ac60ab97aae Author: Chuck Lever Date: Mon Apr 27 09:50:46 2026 -0400 SUNRPC: Add crypto/krb5 enctype lookup to krb5_ctx [ Upstream commit f8b942fc380c3b38b8a0e2d97f020b162fa3f3ae ] Each krb5_ctx currently points to a gss_krb5_enctype, the rpcsec_gss_krb5 module's own enctype descriptor. To begin using the common crypto/krb5 library, store a pointer to the corresponding struct krb5_enctype (from ) as well. The lookup is performed in gss_import_v2_context() immediately after the existing gss_krb5_lookup_enctype() call. If crypto_krb5_find_enctype() cannot find a matching enctype the context import fails, ensuring the module never operates with a partially-initialized krb5_ctx. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: b94f6719dcd9 ("SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2") Signed-off-by: Sasha Levin commit 65f0f82f20334e76acaf29087a59af7b3b9699ed Author: Chuck Lever Date: Wed May 27 11:00:15 2026 -0400 svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails [ Upstream commit 01500306e1d50de7ca7a2cdcdfa28ac0523eb747 ] When svc_rdma_listen_handler() handles RDMA_CM_EVENT_ADDR_CHANGE, it creates a replacement listener cm_id and returns 1, telling the CM core to destroy the old one. If the replacement allocation fails, sc_cm_id still points at the old cm_id that the CM core is about to destroy. Any subsequent dereference of sc_cm_id -- such as svc_rdma_detach()'s rdma_disconnect() call -- is a use-after-free. NULL sc_cm_id on the failure path and guard svc_rdma_detach()'s rdma_disconnect() call against NULL so that the listener can be torn down safely when the server shuts down. Fixes: d1b586e75ec6 ("svcrdma: Handle ADDR_CHANGE CM event properly") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-5-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 35d5dd0c2fd1eb5a75c0774179c51db7b5284a43 Author: Chuck Lever Date: Fri May 22 14:13:57 2026 -0400 svcrdma: wake sq waiters when the transport closes [ Upstream commit e5248a7426030db1e126363f72afdb3b71339a5c ] Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state across transport teardown, pinning svc_xprt references and blocking svc_rdma_free(). The close path sets XPT_CLOSE before invoking xpo_detach and both wait_event predicates include an XPT_CLOSE term, but the predicates are re-evaluated only on wakeup. sc_sq_ticket_wait has no completion-driven wake path; it is advanced solely by the chained ticket handoff inside svc_rdma_sq_wait() itself. Without an explicit wake at close, parked threads never observe XPT_CLOSE, hold their svc_xprt_get reference forever, and svc_rdma_free() blocks on xpt_ref dropping to zero. Two close entry points reach this transport. Local teardown runs svc_rdma_detach() from svc_handle_xprt() -> svc_delete_xprt() -> xpo_detach() on a worker thread. A remote disconnect arrives at svc_rdma_cma_handler(), which calls svc_xprt_deferred_close(): that sets XPT_CLOSE and enqueues the transport but does not access either RDMA waitqueue, so a worker already parked in svc_rdma_sq_wait() never re-evaluates its predicate. With every worker parked on this transport, no thread is available to run the local teardown either, and the wake site there is unreachable. Introduce svc_rdma_xprt_deferred_close(), a thin svcrdma wrapper that calls svc_xprt_deferred_close() and then wakes both sc_sq_ticket_wait and sc_send_wait. Convert the svcrdma producers that called svc_xprt_deferred_close() directly: svc_rdma_cma_handler(), qp_event_handler(), svc_rdma_post_send_err(), svc_rdma_wc_send(), the sendto drop path, the rw completion error paths, and the recvfrom flush and read-list error paths. Wake both waitqueues from svc_rdma_detach() as well. The synchronous svc_xprt_close() path (backchannel ENOTCONN, device removal via svc_rdma_xprt_done) reaches detach without flowing through svc_xprt_deferred_close() and therefore does not invoke the new helper. Fixes: ccc89b9d1ed2 ("svcrdma: Add fair queuing for Send Queue access") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason [ cel: add svc_rdma_xprt_deferred_close() to complete the fix ] Signed-off-by: Chuck Lever [ Adapted for this tree: it has no ticket-based Send Queue waiting, so only sc_send_wait is woken; all svc_xprt_deferred_close() callers in svcrdma are converted to the new wrapper. ] Stable-dep-of: 01500306e1d5 ("svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails") Signed-off-by: Sasha Levin commit f35cf68b1442207a79a6b182e1f04b07a95916dd Author: Chuck Lever Date: Fri Feb 27 09:03:31 2026 -0500 svcrdma: Add Write chunk WRs to the RPC's Send WR chain [ Upstream commit d16f060f3ee297424c0aba047b1d49208adb9318 ] Previously, Write chunk RDMA Writes were posted via a separate ib_post_send() call with their own completion handler. Each Write chunk incurred a doorbell and generated a completion event. Link Write chunk WRs onto the RPC Reply's Send WR chain so that a single ib_post_send() call posts both the RDMA Writes and the Send WR. A single completion event signals that all operations have finished. This reduces both doorbell rate and completion rate, as well as eliminating the latency of a round-trip between the Write chunk completion and the subsequent Send WR posting. The lifecycle of Write chunk resources changes: previously, the svc_rdma_write_done() completion handler released Write chunk resources when RDMA Writes completed. With WR chaining, resources remain live until the Send completion. A new sc_write_info_list tracks Write chunk metadata attached to each Send context, and svc_rdma_write_chunk_release() frees these resources when the Send context is released. The svc_rdma_write_done() handler now handles only error cases. On success it returns immediately since the Send completion handles resource release. On failure (WR flush), it closes the connection to signal to the client that the RPC Reply is incomplete. Signed-off-by: Chuck Lever Stable-dep-of: 01500306e1d5 ("svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails") Signed-off-by: Sasha Levin commit ddbd71a3780942918a7d116d666313e5b3304d73 Author: Guidong Han <2045gemini@gmail.com> Date: Thu Jul 30 17:25:33 2026 +0800 RISC-V: KVM: Fix PMU event info array size overflow [ Upstream commit 735bc20c24187ca419c9d5e63860a54b91be34bd ] SBI PMU EVENT_GET_INFO stores guest-controlled num_events * sizeof(*einfo) in a 32-bit integer. On RV64, num_events = 0x10000001 makes 0x100000010 truncate to 16. KVM then allocates one entry but loops over the original num_events, causing out-of-bounds reads and writes. A nested guest triggered: BUG: KASAN: slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 Read of size 4 at addr ff600000074d46b0 by task init/1 Call Trace: [] kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 [] kvm_sbi_ext_pmu_handler+0xca/0x268 [] kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 [] kvm_riscv_vcpu_exit+0x48c/0x540 [] kvm_arch_vcpu_ioctl_run+0x37e/0xc80 Allocated by task 1: __kmalloc_noprof+0x19e/0x4b0 kvm_riscv_vcpu_pmu_event_info+0x72/0x142 kvm_sbi_ext_pmu_handler+0xca/0x268 kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 kvm_riscv_vcpu_exit+0x48c/0x540 kvm_arch_vcpu_ioctl_run+0x37e/0xc80 The buggy address is located 0 bytes to the right of allocated 16-byte region [ff600000074d46a0, ff600000074d46b0) Store the shared-memory size in size_t and reject multiplication overflow. Allocate the guest-driven array with GFP_KERNEL_ACCOUNT so it is charged to kmemcg, and use __GFP_NOWARN to suppress allocation failure warnings. Use kvcalloc() to allow vmalloc fallback and an unsigned long loop index to match num_events. Reported-by: Naveed Khan Closes: https://lore.kernel.org/kvm/178345245327.72065.13249716450708539854@digiscrypt.com/ Fixes: e309fd113b9f ("RISC-V: KVM: Implement get event info function") Cc: stable@vger.kernel.org Signed-off-by: Guidong Han <2045gemini@gmail.com> Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260730092533.1369531-1-2045gemini@gmail.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 0d4316e30efc8d19766252d8b8df1547ebf77e06 Author: Lukas Gerlach Date: Tue Mar 3 15:19:44 2026 +0100 KVM: riscv: Fix Spectre-v1 in PMU counter access [ Upstream commit 2dda6a9e09ee4f3c30ea72ba949a6ea781205e3a ] Guest-controlled counter indices received via SBI ecalls are used to index into the PMC array. Sanitize them with array_index_nospec() to prevent speculative out-of-bounds access. Similar to x86 commit 13c5183a4e64 ("KVM: x86: Protect MSR-based index computations in pmu.h from Spectre-v1/L1TF attacks"). Fixes: 8f0153ecd3bf ("RISC-V: KVM: Add skeleton support for perf") Reviewed-by: Radim Krčmář Signed-off-by: Lukas Gerlach Link: https://lore.kernel.org/r/20260303-kvm-riscv-spectre-v1-v2-4-192caab8e0dc@cispa.de Signed-off-by: Anup Patel Stable-dep-of: 735bc20c2418 ("RISC-V: KVM: Fix PMU event info array size overflow") Signed-off-by: Sasha Levin commit 0f035333e19944f8ea7a423681f161eb1b2db21c Author: Leon Romanovsky Date: Fri May 1 09:35:05 2026 +0300 ntb: Store original DMA address for future release [ Upstream commit da6d997ac556479c112554ab5d95cbd04683eb11 ] The DMA API requires that dma_free_attrs receive the exact dma_handle originally returned by the allocation function. Do not modify it. Fixes: fc5d1829f9bf ("NTB: transport: Try harder to alloc an aligned MW buffer") Signed-off-by: Leon Romanovsky Reviewed-by: Dave Jiang Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260501-dma-attrs-debug-v2-1-8dbac75cd501@nvidia.com Signed-off-by: Sasha Levin commit b8cd3b632a0ce84d68e1b63ddfebc969e3fc1098 Author: Koichiro Den Date: Fri Mar 6 12:14:42 2026 +0900 NTB: ntb_transport: Use ntb_get_dma_dev() for DMA buffers [ Upstream commit 852b94ff92cbe26a0dbb15eed9474f5493767f3b ] ntb_transport currently uses ndev->pdev->dev for coherent allocations and frees. Switch the coherent buffer allocation/free paths to use ntb_get_dma_dev(), so ntb_transport can work with NTB implementations where the NTB PCI function is not the right device to use for DMA mappings. Suggested-by: Frank Li Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260306031443.1911860-3-den@valinux.co.jp Stable-dep-of: da6d997ac556 ("ntb: Store original DMA address for future release") Signed-off-by: Sasha Levin commit 6a01c4d3a3ae1f0b93c2446d237fd99499e9cd1e Author: Koichiro Den Date: Fri Mar 6 12:14:41 2026 +0900 NTB: core: Add .get_dma_dev() callback to ntb_dev_ops [ Upstream commit 362a4549f2acfb03390ddfcd91041e65a11a739f ] Some NTB implementations are backed by a PCI function that is not the right struct device to use with DMA API helpers (e.g. due to IOMMU topology, or because the NTB device is virtual). Add an optional .get_dma_dev() callback to struct ntb_dev_ops and provide a helper, ntb_get_dma_dev(), so NTB clients can use the appropriate struct device for DMA allocations and mappings. If the callback is not implemented, ntb_get_dma_dev() returns the current default (ntb->dev.parent). Drivers that implement .get_dma_dev() must return a non-NULL device. Suggested-by: Frank Li Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam [bhelgaas: format doc] Signed-off-by: Bjorn Helgaas Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260306031443.1911860-2-den@valinux.co.jp Stable-dep-of: da6d997ac556 ("ntb: Store original DMA address for future release") Signed-off-by: Sasha Levin commit 7672973957e3e20780afe5937a9fec70b72bc060 Author: Eric Dumazet Date: Tue Jun 23 17:30:30 2026 +0000 tipc: avoid busy looping in tipc_exit_net() [ Upstream commit c1481c94e74c955e0448ddf46b8615a44d840c1e ] Blamed commit introduced a busy-wait loop in tipc_exit_net() to wait for pending UDP bearer cleanup works to complete: while (atomic_read(&tn->wq_count)) cond_resched(); This loop can busy-wait for a long time if cond_resched() is a NOP. This typically happens if the netns exit is executed by a high priority task, or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In such cases, it wastes CPU cycles and can lead to soft lockups. Fix this by replacing the busy loop with wait_var_event(), allowing the thread to sleep properly until the work queue count reaches zero. Accordingly, update cleanup_bearer() to use atomic_dec_and_test() and wake_up_var() to wake up the waiter when the count drops to zero. This uses the global wait queue hash table, avoiding the need to bloat struct tipc_net with a wait_queue_head_t. The atomic_dec_and_test() provides the necessary memory barrier to ensure the wakeup is not missed. Fixes: 04c26faa51d1 ("tipc: wait and exit until all work queues are done") Signed-off-by: Eric Dumazet Cc: Jon Maloy Cc: tipc-discussion@lists.sourceforge.net Reviewed-by: Xin Long Link: https://patch.msgid.link/20260623173030.2925059-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ed7e9715849abd0816b8487b0d12ebd05d6e938b Author: Thomas Zimmermann Date: Wed May 27 17:14:02 2026 +0200 fbdev: Wrap user-invoked calls to fb_set_var() in helper [ Upstream commit 6f611e5e5f3327cf2e2daabe6ee5acac58cc784e ] Handle fbcon during display updates in fb_set_var_from_user(). Check with fbcon if the mode change is possible, update hardware state and finally update fbcon. Update all callers. Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other mode-changes callers in sysfs and driver code are missing fbcon-related steps. With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain fbcon state themselves. Signed-off-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 69164d6bdad5d6657e51436a3f602822f620a46a Author: William Palacek Date: Mon Jul 6 10:25:58 2026 -0400 drm/amdkfd: Add bounds check for CRAT subtype length [ Upstream commit 6e7566ba4739dd573c331adde1c96690f7a567bd ] The CRAT parser validates that the subtype header fits within the image, but does not verify that the advertised subtype length fits. A malformed CRAT table with an oversized length field causes out-of-bounds reads when kfd_parse_subtype() casts the header to specific subtype structures. Add validation that sub_type_hdr + length does not exceed the image boundary before parsing the subtype contents. Signed-off-by: William Palacek Reviewed-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 39841db9322cddf7bd1dbcacdffc791475c7b02f Author: Yongqiang Sun Date: Mon Jun 1 15:28:30 2026 -0400 drm/amdkfd: Fix infinite loop parsing CRAT with zero subtype length [ Upstream commit 961323c26ad4c895e3b0ea1711fc41dfd6368c12 ] Malformed ACPI CRAT tables can advertise a zero or undersized subtype length. The parser then fails to advance the cursor and loops forever while the remaining image still looks large enough for a generic header. Validate sub_type_hdr->length on each iteration before parsing or advancing. Return -EINVAL and warn when length is zero or smaller than the generic subtype header. Signed-off-by: Yongqiang Sun Acked-by: Alex Deucher Signed-off-by: Alex Deucher Stable-dep-of: 6e7566ba4739 ("drm/amdkfd: Add bounds check for CRAT subtype length") Signed-off-by: Sasha Levin commit 22c2169770ad3b3595690e51caac875178cf496d Author: Luxiao Xu Date: Tue Aug 4 22:29:01 2026 +0800 bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie [ Upstream commit 31a420a822ff92e2090bd5d65efe8e34e2d6d9b8 ] bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie accept a socket pointer 'sk' with argument type ARG_PTR_TO_BTF_ID_SOCK_COMMON. However, they access sk->sk_protocol without validating whether 'sk' represents a full socket. Fix this issue by checking sk->sk_state != TCP_LISTEN before inspecting sk->sk_protocol in both bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie. Since mini-sockets are never in the TCP_LISTEN state, the condition short-circuits and prevents dereferencing fullsock-specific fields. Fixes: 399040847084 ("bpf: add helper to check for a valid SYN cookie") Fixes: 70d66244317e ("bpf: add bpf_tcp_gen_syncookie helper") Reported-by: Vega Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Daniel Borkmann Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/bpf/6218aa3534d0d2d3f448fde70a8dc2769d7a8201.1785823138.git.rakukuip@gmail.com Signed-off-by: Sasha Levin commit bea1f73ad69eec36b757adb8e63beb3092f862ee Author: Alex Deucher Date: Mon Feb 16 09:32:53 2026 -0500 drm/amd/display: check if dml21_add_phantom_plane() is successful [ Upstream commit 000acb4ce7fb9feba3072ce468ad681f6585cd5d ] Verify that the phantom plane was allocated to avoid a later segfault. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4970 Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources") Reviewed-by: Dillon Varone Signed-off-by: Fangzhi Zuo Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 63844dc03960b09b36746eda636c08f1479407ce Author: Yuho Choi Date: Wed Apr 15 16:54:52 2026 -0400 dmaengine: idxd: fix double free of wq, engine, and group structs [ Upstream commit ec2d428b2e32dd157de8f86a86dd85c5b2c8f45c ] The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks. Fixes: 7c5dd23e57c1 ("dmaengine: idxd: fix wq conf_dev 'struct device' lifetime") Fixes: 75b911309060 ("dmaengine: idxd: fix engine conf_dev lifetime") Fixes: defe49f96012 ("dmaengine: idxd: fix group conf_dev lifetime") Signed-off-by: Yuho Choi Acked-by: Vinicius Costa Gomes Reviewed-by: Frank Li Link: https://patch.msgid.link/20260415205452.67155-1-dbgh9129@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e299b7d1334ebec4d43a7bb697d10c12df1aaed3 Author: Michael Bommarito Date: Wed Jun 17 17:57:54 2026 -0400 idpf: bound interrupt-vector register fill to the allocated array [ Upstream commit 9f7007ee9858c99aa43101bc8352c672fee85644 ] idpf_get_reg_intr_vecs() fills the caller-allocated reg_vals[] array from the VIRTCHNL2_OP_ALLOC_VECTORS reply in adapter->req_vec_chunks, bounding its inner loop only by the per-chunk num_vectors. The array is sized separately: idpf_intr_reg_init() allocates kzalloc_objs(struct idpf_vec_regs, total_vecs) from caps.num_allocated_vectors and only checks the returned count after the fill. The sum of per-chunk num_vectors is never reconciled against total_vecs, so a reply with a small num_allocated_vectors but chunks summing higher writes past the end of reg_vals[]. Impact: a control plane (a PF or hypervisor device model) that returns a VIRTCHNL2_OP_ALLOC_VECTORS reply whose per-chunk num_vectors sum exceeds num_allocated_vectors writes struct idpf_vec_regs entries past the end of the reg_vals kmalloc allocation (KASAN slab-out-of-bounds write). Bound the fill loop to the array capacity passed in by the callers, mirroring the sibling idpf_vport_get_q_reg(). The existing num_regs < num_vecs check then rejects an undersized reply without the out-of-bounds write happening first. Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Aleksandr Loktionov Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a4de6fc95b2f36967fc247ae51cad2171194f7cd Author: Pauli Virtanen Date: Sat Jul 25 12:59:18 2026 +0300 Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks [ Upstream commit 2f5d635ad5906b0235bc0c870e8beba3116e1e98 ] There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Fixes: 881559af5f5c ("Bluetooth: hci_sync: Attempt to dequeue connection attempt") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e124f7b170337563d78a7a6aa152c897d229bc39 Author: Prasanna Kumar T S M Date: Thu Mar 19 23:03:06 2026 -0700 soc: xilinx: Fix race condition in event registration [ Upstream commit fb445935338405110baca8f541a2df3b4cb8d712 ] The zynqmp_power driver registers handlers for suspend and subsystem restart events using register_event(). However, the work structures (zynqmp_pm_init_suspend_work and zynqmp_pm_init_restart_work) used by these handlers were allocated and initialized after the registration call. This created a race window where, if the firmware triggered an event immediately after registration but before allocation, the callback (suspend_event_callback or subsystem_restart_event_callback) would dereference a NULL pointer in work_pending(), leading to a crash. Fix this by allocating and initializing the work structures before registering the events. Fixes: fcf544ac6439 ("soc: xilinx: Add cb event for subsystem restart") Signed-off-by: Prasanna Kumar T S M Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260320060306.1540928-1-ptsm@linux.microsoft.com Signed-off-by: Sasha Levin commit afef4b0de4f3c49cd278221f593b8e4c0390b7e4 Author: Jay Buddhabhatti Date: Tue Jul 1 05:38:51 2025 -0700 drivers: firmware: xilinx: Switch to new family code in zynqmp_pm_get_family_info() [ Upstream commit 25e3ae0ce364fa725a6eea68d63d6a2ee09e019f ] Currently, the family code and subfamily code are derived from the PMC_TAP_IDCODE register. Versal, Versal NET share the same family code. Also some platforms share the same subfamily code, making it difficult to distinguish between platforms. Update zynqmp_pm_get_family_info() to use IDs derived from the compatible string instead of silicon ID codes derived from PMC_TAP_IDCODE register. Signed-off-by: Jay Buddhabhatti Link: https://lore.kernel.org/r/20250701123851.1314531-4-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek Stable-dep-of: fb4459353384 ("soc: xilinx: Fix race condition in event registration") Signed-off-by: Sasha Levin commit a19c48d9f5a73f2333b1fd994d8a47126e5c73e8 Author: Jay Buddhabhatti Date: Tue Jul 1 05:38:50 2025 -0700 drivers: firmware: xilinx: Add unique family code for all platforms [ Upstream commit e66f4c35e375346943bfe2a0990e97253f74440f ] The family code is currently derived from the PMC_TAP_IDCODE register value, but there are issues where Versal, Versal NET, and future platforms share the same family code. Additionally for some platforms have identical subfamily code, making it challenging to differentiate between platforms based on the family and subfamily codes. To resolve this, a new family code member is added to the platform data, initialized with unique values. This change enables better platform distinction via the compatible string. Signed-off-by: Jay Buddhabhatti Link: https://lore.kernel.org/r/20250701123851.1314531-3-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek Stable-dep-of: fb4459353384 ("soc: xilinx: Fix race condition in event registration") Signed-off-by: Sasha Levin commit 547ea9f567498e4accc89e7816264f15a1a0629f Author: David Carlier Date: Sat May 23 16:26:21 2026 +0100 netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag [ Upstream commit e052f920773b73be49eb4d8702a9f85de7464363 ] The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the decrement still happens and wraps it to 255. The break only leaves the inner switch -- a later path entry can set info->indev back to a real device, and we end up returning with num_encaps == 255. nft_dev_forward_path() then walks info.encap[] (size 2) up to num_encaps, which means an OOB stack read and a bogus count copied into the route descriptor. Should only happen on a malformed bridge path stack, hence the WARN, but worth handling sanely. Move the decrement out of the WARN. [ While at this, remove the WARN_ON_ONCE since this can only happen with a buggy bridge path stack --pablo ]. Fixes: e990cef6516d ("netfilter: flowtable: add bridge vlan filtering support") Signed-off-by: David Carlier Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit be7fb59512ffc2da5d98214a00117dfe9eccab78 Author: Weiming Shi Date: Wed Oct 7 00:50:59 2026 -0400 btrfs: lzo: reject compressed segment that overflows the compressed input [ Upstream commit b0d27d43791b7a3057c3c4aedf9b4aa033d37c46 ] lzo_decompress_bio() validates each on-disk segment length seg_len only against the workspace cbuf size, not against the compressed input size (compressed_len, the total folio bytes of the bio). A crafted extent can carry a segment whose seg_len passes the cbuf check but runs past the end of the bio, so copy_compressed_segment() walks off the last folio: get_current_folio() then returns the NULL folio from bio_next_folio(), and with CONFIG_BTRFS_ASSERT disabled (default) folio_size(NULL) faults. BUG: KASAN: null-ptr-deref in lzo_decompress_bio (fs/btrfs/lzo.c:383) Read of size 8 at addr 0000000000000000 by task kworker/u8:1/29 Workqueue: btrfs-endio simple_end_io_work kasan_report (mm/kasan/report.c:590) lzo_decompress_bio (fs/btrfs/lzo.c:383) end_bbio_compressed_read (fs/btrfs/compression.c:1065) btrfs_bio_end_io (fs/btrfs/bio.c:135) btrfs_check_read_bio (fs/btrfs/bio.c:180 fs/btrfs/bio.c:285) simple_end_io_work process_one_work worker_thread Reject any segment whose payload would extend beyond compressed_len before copying it, treating it as corruption like the other on-disk validation failures in this function. Reported-by: Xiang Mei Fixes: a6e66e6f8c1b ("btrfs: rework lzo_decompress_bio() to make it subpage compatible") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Qu Wenruo Signed-off-by: Weiming Shi Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0977a6f23439616701282fc4cb38eca40f36fec6 Author: Mostafa Saleh Date: Wed Jun 17 14:51:24 2026 +0000 optee: ffa: Add NULL check in optee_ffa_lend_protmem [ Upstream commit 650c88738ae8976f46ba71b24dd8aa311adc6fde ] Sashiko (locally) reports a possible null dereference under memory pressure due to the lack of validation of the allocated pointer. Fix that by adding the missing check. Fixes: 2b78d79cdf96 ("optee: FF-A: dynamic protected memory allocation") Signed-off-by: Mostafa Saleh Signed-off-by: Sebastian Ene Reviewed-by: Sumit Garg Reviewed-by: Sebastian Ene Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit fdc93f4a801077efbf1b87570ade8d8f325de62f Author: Hongjie Fang Date: Wed Jul 29 19:16:14 2026 +0800 scsi: core: pair EH runtime PM get and put [ Upstream commit 872f486259ae0bc6b73ca4735a15d013241f73e9 ] shost->eh_noresume is currently consulted twice in one error handling iteration: once before scsi_autopm_get_host() and once again before scsi_autopm_put_host(). That is racy when a PM-triggered error path flips shost->eh_noresume while the SCSI EH thread is still running. The problem flow looks like this: PM path ufshcd_set_dev_pwr_mode() shost->eh_noresume = 1 ufshcd_execute_start_stop <-- trigger EH ... shost->eh_noresume = 0 EH path scsi_error_handler() if (!shost->eh_noresume) scsi_autopm_get_host() <-- skipped ... if (!shost->eh_noresume) scsi_autopm_put_host() <-- executed later In that case one EH iteration can skip autoresume on entry and still drop a runtime PM reference on exit. That leaves an unmatched runtime PM put and can trigger a runtime PM usage count underflow. Fix this by making eh_noresume a regular bool so it can be accessed with READ_ONCE() and WRITE_ONCE(). Snapshot it once per EH iteration and use that snapshot for both runtime PM get and put decisions. Fixes: ae0751ffc77e ("[SCSI] add flag to skip the runtime PM calls on the host") Signed-off-by: Hongjie Fang Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260729111614.2407559-1-hongjiefang@asrmicro.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 5cea365559449f2149ab724d33d406e3ec4c00c9 Author: Ralf Lici Date: Wed Jul 29 12:21:46 2026 +0200 ovpn: defer key slot crypto freeing to workqueue [ Upstream commit 2da3dfa1ddfe55a065f484750c83660e3bd4ac00 ] Key slots are released through a kref and the existing release path frees the AEAD transforms from an RCU callback. That is not safe for all crypto implementations: crypto_free_aead can sleep, for example when an async or hardware implementation has teardown work to complete. Use queue_rcu_work for key-slot release. This keeps the RCU grace period needed by lockless key-slot readers, but runs the actual crypto teardown from workqueue context where sleeping is allowed. Once the rcu_work callback runs, pre-existing RCU readers are gone, and the final kref put already proves that no transform user remains, so the worker can release the AEAD transforms and free the slot directly. The previous patch drains ovpn_wq during module exit, so queued key-slot teardown work cannot outlive module text. Fixes: 8534731dbf2d ("ovpn: implement packet processing") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit eb81c8e758f49e04391f77d9470a6232bb5f1c7a Author: Julian Anastasov Date: Thu Aug 6 13:52:11 2026 +0300 ipvs: revalidate ihl to prevent out-of-bounds access [ Upstream commit d93660df4dd1d116f608ada4a29a80a5d6f0a6ed ] While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access. One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls. Add check to drop the packet if the ihl field is changed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260730183506.87473-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d10e73572cda4af7487f82f58a7771f18cf61084 Author: Jakub Kicinski Date: Mon Aug 3 12:31:35 2026 -0700 eth: bnxt: avoid deadlock when canceling IRQ affinity notifier [ Upstream commit 51e96fa31f7e7eac2cba8f854e24d36600cc040b ] Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock. Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out. In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed. There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Tested-by: Vishvambar Panth S Link: https://patch.msgid.link/20260803193135.2030368-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21f5381a57a5f897014392a1df538e39af0347e5 Author: Jakub Kicinski Date: Mon Aug 3 12:31:34 2026 -0700 eth: bnxt: decrease indent in bnxt_request_irq() [ Upstream commit 0fd562c7b9e48e7958f7405e54bf98e8e22ad184 ] bnxt_request_irq() has unnecessary level of indentation. Use continue instead. No need to re-fetch NUMA node for each IRQ, move to the function level. No functional changes. Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260803193135.2030368-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 51e96fa31f7e ("eth: bnxt: avoid deadlock when canceling IRQ affinity notifier") Signed-off-by: Sasha Levin commit bf3f37c2d40b51deb79aea910f28999d7c8c6b5a Author: Mark Tomlinson Date: Thu Jul 9 16:51:16 2026 +1200 gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock [ Upstream commit 9dc325327babe7f159e84cbe9380a45342da0585 ] Locking is disabled in the regmap config as this driver uses its own lock. This means that all calls to regmap functions (read or write) must hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do this, and it was therefore possible that multiple threads could cause an incorrect register to be read/written. A previous patch partly fixed this, but only protected the write to the interrupt mask register, and not the read from the direction register. Fixes: bfc6444b57dc ("gpio: pca953x: fix pca953x_irq_bus_sync_unlock race") Cc: stable@vger.kernel.org Signed-off-by: Mark Tomlinson Link: https://patch.msgid.link/20260709045116.2304246-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 868c478abce858135db3eb65548a577e4b6747ac Author: Karthikeyan KS Date: Fri Jun 12 19:07:43 2026 +0000 soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read [ Upstream commit 1acef6d85bfd98bd9dfe1f08bffa397a4dda8a6f ] put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store: usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-2k' (offset 0, size 2049)! kernel BUG at mm/usercopy.c! Call trace: usercopy_abort __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read Serialize kfifo access with a per-channel spinlock shared between the IRQ handler (producer) and the file reader (consumer). Annotate @fifo with __guarded_by(&lock) and opt the driver into context analysis so the compiler enforces that all fifo access holds the lock. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Karthikeyan KS Signed-off-by: Andrew Jeffery Signed-off-by: Sasha Levin commit 056876c9db1e969bfcf7d8583c7696cc0dd080df Author: David Lee Date: Wed Jul 15 09:05:14 2026 +0000 btrfs: lzo: reject inline extents without valid headers [ Upstream commit 0fa78ef637deb5dbe341582f88553a4bce496de0 ] [BUG] For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent: BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700 Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77 Call Trace: dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110 __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/0x10a0 btrfs_do_readpage.constprop.0+0x538/0x1ac0 btrfs_readahead+0x32f/0x5f0 read_pages+0x16f/0x850 page_cache_ra_unbounded+0x296/0x490 do_page_cache_ra+0xd9/0x130 page_cache_sync_ra+0x3ee/0x6f0 filemap_get_pages+0x306/0x15c0 filemap_read+0x329/0xd00 btrfs_file_read_iter+0x1f8/0x2b0 vfs_read+0x4ef/0x720 ksys_read+0xf8/0x1d0 __x64_sys_read+0x71/0xb0 x64_sys_call+0x1ab0/0x1b70 do_syscall_64+0x61/0x470 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] For an inline lzo compressed file extent, there should always be one lzo header, recording the total length of the compressed data, followed by one segment header, recording the compressed lzo payload. But if a crafted inline lzo compressed file extent contains only an lzo header, without the segment header or payload, lzo_decompress() will still try to read the segment header, causing a read beyond the item boundary. Furthermore if the inline lzo compressed file extent is the first item of the leaf, it will be at the extent buffer boundary. The above out-of-boundary read will go beyond the extent buffer boundary, triggering the above KASAN report. [FIX] Validate the total length of the inlined lzo compressed file extent, to make sure there is at least one LZO header and one segment header, and a non-zero payload. Fixes: a6fa6fae40ec ("btrfs: Add lzo compression support") Assisted-by: Codex:gpt-5.5 Signed-off-by: David Lee [ Rework the commit message to remove slop ] Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 618fc8dc219c11b8b85f0c8e3f7ff46cc1544339 Author: Lizhi Hou Date: Fri Jul 31 11:59:55 2026 -0700 accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages() [ Upstream commit 4a19f7ab5972ef608b31ae921419bc3e04b3f8ad ] In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM object and then calls madvise(MADV_DONTNEED), the PTEs will be successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP). When userspace subsequently accesses the memory, drm_gem_shmem_fault() handles the page fault and attempts to map the backing shmem page via vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA now has VM_MIXEDMAP set, won't this predictably trigger the explicit assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn)) Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages() pre-population with the handle_mm_fault() loop that was already used for the import (dma-buf) path. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260731185955.3449311-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit b3d05a335cbd3d89538e9dde1621dccf33ae945a Author: Lizhi Hou Date: Thu Jul 23 00:42:56 2026 -0700 accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages() [ Upstream commit 8d51e0fd3e698919d2adeff71936377f0c0d4aa0 ] Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma) before returning an error code to the caller. This is incorrect: amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo that registration. Calling vm_ops->close() manually — which drops the shmem pages_pin_count and the GEM object reference that backs the VMA — before the mmap syscall has even returned causes those resources to be released while the VMA is still alive. The kernel VMA teardown will call vm_ops->close() a second time when the process later unmaps the range, producing a reference count underflow. Replace both hard-error returns with a deferred-fault approach that keeps the VMA alive and retries page insertion through the HMM range-fault path. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260723074256.2435143-1-lizhi.hou@amd.com Stable-dep-of: 4a19f7ab5972 ("accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()") Signed-off-by: Sasha Levin commit 4af94462c0ca2187a02a1a6641020ae888c74d5c Author: Chengfeng Ye Date: Sat Aug 1 00:09:21 2026 +0800 bpf: Fix netns reference imbalance in conntrack kfuncs [ Upstream commit fdeba03fea78407a8c52faa99177c9f7f29f90eb ] The opts argument of the BPF conntrack kfuncs can point to a shared map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read opts->netns_id separately when acquiring and releasing the network namespace reference. The reference imbalance can occur as follows: CPU 0 CPU 1 read opts->netns_id (-1) skip get_net_ns_by_id() write opts->netns_id (id) read opts->netns_id (id) put_net(net) /* no matching get */ The reverse transition leaks the reference. Repeating the unmatched put can destroy a live namespace and crash later users. The kernel reported: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700 Call Trace: __sys_bpf+0x1662/0x50c0 __x64_sys_bpf+0x73/0xb0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Snapshot every input field of opts with READ_ONCE() before validating or using it. The netns_id snapshot keeps the namespace get/put pair balanced, while the other snapshots keep the remaining options from changing partway through an invocation. The individual reads can still observe an inconsistent combination during a concurrent update, but each selected field value remains stable for that invocation. Fixes: aed8ee7feb44 ("net: netfilter: Deduplicate code in bpf_{xdp,skb}_ct_lookup") Fixes: d7e79c97c00c ("net: netfilter: Add kfuncs to allocate and insert CT") Signed-off-by: Chengfeng Ye Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260731160921.3245840-1-nicoyip.dev@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit b57164cdddb46924ff9fa191b727ca097744de88 Author: Linfeng Sun Date: Sat Jun 20 21:00:05 2026 +0800 vhost_iotlb: bound map allocation in add_range [ Upstream commit 1ed35ac7f3fe2b4396bdd29ac3a7f0ebc0829e94 ] vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error. Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries. Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind. When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL. I found this bug myself, though the patch was written with AI assistance. Fixes: 0bbe30668d89 ("vhost: factor out IOTLB") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun  Message-ID: Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 2b80707b9e27671e10840d17c6f8f774c4ad9847 Author: Steven Rostedt Date: Sat Aug 8 09:42:15 2026 -0400 eventfs: Use children field for rcu head and add memory barriers [ Upstream commit f0ece16ffca7384787b692431961ce202907acf5 ] When an eventfs inode is freed, it sets ei->is_freed and then uses its ei->list to add it to the srcu link list as the list field is a union with the rcu list head. As the ei->list is used to iterate over an SRCU protected list without taking the eventfs_mutex, there's nothing stopping the iteration over that list to see the ei->rcu instead of the ei->list and it will read a corrupt target. To fix this, change the union of the rcu list head with the children list. On freeing the eventfs inode, set the is_free and execute a smp_wmb() before adding the eventfs inode to the SRCU list. On iteration of the ei->children list, at the start, execute a smp_rmb() and then read the is_freed of the ei to see if the children list is still valid. If is_freed is set, then the ei_child read is not valid and the loop should exit immediately. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808094215.4252430d@robin Fixes: 704f960dbee2f ("eventfs: Read ei->entries before ei->children in eventfs_iterate()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260806022719.375354-1-shuangpeng.kernel%40gmail.com Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 969a96479add6bd42d7f7241f99f27b31571a953 Author: Dongjiang Zhu Date: Mon Jul 13 16:50:08 2026 +0800 btrfs: skip global block reserve accounting for rescue mounts [ Upstream commit 51a0e8399858621442807a26057bcd1cd3ced046 ] [BUG] Mounting with rescue=ibadroots after corrupting the block group tree root triggers a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000100 RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs] Call Trace: fill_dummy_bgs+0xd4/0x120 [btrfs] open_ctree+0xc6e/0x1ca0 [btrfs] btrfs_get_tree+0x50d/0xa40 [btrfs] The same crash occurs with a corrupted raid stripe tree root, via btrfs_read_block_groups() instead of fill_dummy_bgs(). [CAUSE] With rescue=ibadroots, btrfs_read_roots() allows the mount to continue when either root cannot be read, leaving the corresponding root pointer NULL while its on-disk feature bit remains set. btrfs_update_global_block_rsv() then dereferences the missing root based on the feature bit alone. [FIX] Rescue mounts are fully read-only and cannot start transactions, so the global reserve is never consumed. Under btrfs_is_full_ro(), mark the reserve as full and return before performing the accounting. And since we need to check if the fs is mount fully RO, export fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h. Fixes: 8dbfc14fc736 ("btrfs: account block group tree when calculating global reserve size") Fixes: 515020900d44 ("btrfs: read raid stripe tree from disk") Suggested-by: Qu Wenruo Signed-off-by: Dongjiang Zhu [ Squash the fs_is_full_ro() export commit into this one. ] Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f5427cab065641a4553d38bb8c4932b8d456c7a7 Author: Qu Wenruo Date: Thu Apr 30 10:37:23 2026 +0930 btrfs: warn about extent buffer that can not be released [ Upstream commit 83f7e52b7ed1c3e03b79123e20b6f6adf8d886bb ] When we unmount the fs or during mount failures, btrfs will call invalidate_inode_pages() to release all btree inode folios. However that function can return -EBUSY if any folios can not be invalidated. This can be caused by: - Some extent buffers are still held by btrfs This is a logic error, as we should release all tree root nodes during unmount and mount failure handling. - Some extent buffers are under readahead and haven't yet finished These are much rarer but valid cases. In that case we should wait for those extent buffers. Introduce a new helper invalidate_and_check_btree_folios() which will: - Call invalidate_inode_pages2() and catch its return value If it returned 0 as expected, that's great and we can call it a day. - Otherwise go through each extent buffer in buffer_tree Increase the ref by one first for the eb we're checking. This is to ensure the eb won't be freed after the readahead is finished. For ebs that still have EXTENT_BUFFER_READING flag, wait for them to finish first. After waiting for the readahead, check the refs of the eb and if it's still dirty. If the eb ref count is greater than 2 (one for the buffer tree, one held by us), it means we are still holding the extent buffer somewhere else, which is a code bug. If the eb is still dirty, it means a bug in transaction handling, e.g. the bug fixed by patch "btrfs: only release the dirty pages io tree after successful writes". For either case, show a warning message about the eb, including its bytenr, owner, refs and flags. And if it's a debug build, also trigger WARN_ON_ONCE() so that fstests can properly catch such situation. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221270 Reported-by: AHN SEOK-YOUNG CC: Teng Liu <27rabbitlt@gmail.com> Tested-by: Teng Liu <27rabbitlt@gmail.com> Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: 51a0e8399858 ("btrfs: skip global block reserve accounting for rescue mounts") Signed-off-by: Sasha Levin commit 23b0f4117e970406f4a62e9b36e807b0452e7507 Author: Qu Wenruo Date: Tue Mar 31 08:51:56 2026 +1030 btrfs: only invalidate btree inode pages after all ebs are released [ Upstream commit 48aa5c0e2bb85dae61a6cb405094eb135c711a04 ] In close_ctree(), we call invalidate_inode_pages2() to invalidate all pages from btree inode. But the problem is, it never returns 0, but always -EBUSY. The problem is that we are still holding all the essential tree root nodes, thus pages holding those tree blocks can not be invalidated thus invalidate_inode_pages2() always returns -EBUSY. This is also against the error cleanup path of open_ctree(), which properly frees all root pointers before calling invalidate_inode_pages(). So fix the order by delaying invalidate_inode_pages2() until we have freed all root pointers. Reviewed-by: Anand Jain Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: 51a0e8399858 ("btrfs: skip global block reserve accounting for rescue mounts") Signed-off-by: Sasha Levin commit a6f972c50552ef44a155dc83d4669de11c8b270c Author: David Sterba Date: Tue Jan 6 13:30:28 2026 +0100 btrfs: split btrfs_fs_closing() and change return type to bool [ Upstream commit e582f22030a7a59d4d0bb2881371df259d4a2ecd ] There are two tests in btrfs_fs_closing() but checking the BTRFS_FS_CLOSING_DONE bit is done only in one place load_extent_tree_free(). As this is an inline we can reduce size of the generated code. The types can be also changed to bool as this becomes a simple condition. text data bss dec hex filename 1674006 146704 15560 1836270 1c04ee pre/btrfs.ko 1673772 146704 15560 1836036 1c0404 post/btrfs.ko DELTA: -234 Reviewed-by: Filipe Manana Signed-off-by: David Sterba Stable-dep-of: 51a0e8399858 ("btrfs: skip global block reserve accounting for rescue mounts") Signed-off-by: Sasha Levin commit f8e5715a37378ea1a140ee1162fa441e149c5142 Author: Carlos López Date: Wed Jul 15 12:51:37 2026 +0200 KVM: arm64: vgic: Fix race between LPI release and re-registration [ Upstream commit cbfe2b24a1ea9de35032dbdd100fdc700f5be92d ] Fix a potential race between decrementing an LPI's reference count and evicting that structure from the LPI xarray. LPI structures are maintained in the VGIC LPI xarray (dist->lpi_xa). When the reference count of an LPI structure drops to zero, vgic_release_lpi_locked() removes the structure from the xarray and frees it under the xarray lock. However, the release of an LPI can race with a concurrent LPI re-registration with the same INTID via vgic_add_lpi() on another CPU, since the reference count drop and the xarray eviction are not performed in a single atomic step. This can happen e.g. if the guest issues a DISCARD while the LPI is still referenced from a vCPU's active-pending list (ap_list), and the same INTID is re-mapped via MAPTI. Particularly, vgic_release_lpi_locked() is called from two distinct paths: direct release via vgic_put_irq(), and deferred release via vgic_release_deleted_lpis(). During direct release, the issue can result in deleting a newly registered LPI from the xarray: CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgic_put_irq() __vgic_put_irq() refcount_dec_and_test() vgic_add_lpi() xa_lock_irqsave() old_irq = xa_load(.., intid) vgic_try_get_irq_ref(old_irq) == false new IRQ inserted --> __xa_store(.., intid, ..) xa_unlock_irqrestore() xa_lock_irqsave(); vgic_release_lpi_locked() __xa_erase(.., irq->intid) <-- BUG: new IRQ is erased kfree_rcu(old_irq) During the deferred release path, the old IRQ can be leaked: CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgic_put_irq_norelease() __vgic_put_irq() refcount_dec_and_test() irq->pending_release = true vgic_add_lpi() xa_lock_irqsave() old_irq = xa_load(.., intid) vgic_try_get_irq_ref(oldirq) == false BUG: old IRQ overwritten --> __xa_store(.., intid, ..) xa_unlock_irqrestore() vgic_release_deleted_lpis() xa_lock_irqsave() xa_for_each() { .. } <-- old IRQ with pending_release = true is gone, so it cannot be released To fix the direct release path, move the reference count drop inside the xarray lock, making sure that vgic_add_lpi() never encounters the to-be-released LPI. In the deferred release path, the refcount drop must happen under a raw spinlock, so the xarray lock cannot be grabbed, and the same solution does not work. Instead, update vgic_add_lpi(), so that if it evicts an LPI from the xarray, it takes on the responsibility of freeing it. Consequently, an LPI may now be freed concurrently after a deferred release drops the refcount, so accessing the pending_release field is no longer safe from use-after-free. Delete all uses of the flag, and update vgic_release_deleted_lpis() to identify orphaned LPIs purely based on their refcount. Reported-by: Claude:claude-opus-4-6 Fixes: 3a08a6ca7c37 ("KVM: arm64: vgic-v3: Use bare refcount for VGIC LPIs") Fixes: d54594accf73 ("KVM: arm64: vgic-v3: Erase LPIs from xarray outside of raw spinlocks") Signed-off-by: Carlos López Link: https://patch.msgid.link/20260715105137.3973823-4-clopez@suse.de Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 4b296d176580a85ccbc7135ebdf66c42087b23a2 Author: Xiang Mei (Microsoft) Date: Wed Jul 22 00:29:50 2026 +0000 nexthop: take nh->lock for f6i_list walks in replace check and notify [ Upstream commit 072cd1f21819dedd2252e704d255de3b0cfc61a7 ] fib6_check_nh_list() and __nexthop_replace_notify() walk nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock. IPv6 RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under nh->lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a concurrent route delete that unlinks and frees a fib6_info: BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799) Read of size 4 at addr ffff888014607e64 by task exploit/143 rt6_fill_node.isra.0 (net/ipv6/route.c:5799) fib6_rt_update (net/ipv6/route.c:6412) __nexthop_replace_notify (net/ipv4/nexthop.c:2542) rtm_new_nexthop (net/ipv4/nexthop.c:2554) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605) Read of size 8 at addr ffff888014a7d068 by task exploit/142 fib6_check_nh_list (net/ipv4/nexthop.c:1605) rtm_new_nexthop (net/ipv4/nexthop.c:2575) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Both walks only read the entries and take no tb6_lock, so protect them with nh->lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC under the lock. Fixes: 081efd18326e ("ipv6: Protect nh->f6i_list with spinlock and flag.") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260722002951.2614721-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f97fae992155b11da516a509c855ff9d0868b107 Author: Xiang Mei (Microsoft) Date: Wed Jul 22 00:29:51 2026 +0000 nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush [ Upstream commit 4787a6d2629b4e8c0b6bacab1f75c1660eca44d9 ] nh_rt_cache_flush() walks nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock, racing the unlocked IPv6 route add/delete that mutate the list under nh->lock and free fib6_info entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()): BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243) Read of size 8 at addr ffff888012953e18 by task exploit/146 nh_rt_cache_flush (net/ipv4/nexthop.c:2243) replace_nexthop (net/ipv4/nexthop.c:2610) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Unlike the other f6i_list walks, this one bumps each route's sernum via fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh->lock around it would invert the established tb6_lock -> nh->lock order and deadlock. As the only purpose is to invalidate cached dsts, bump the IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead, mirroring the rt_cache_flush() already done for IPv4 just above. Fixes: 081efd18326e ("ipv6: Protect nh->f6i_list with spinlock and flag.") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260722002951.2614721-2-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2c0a8cc97a9d970a252f17aa0bbf4588768f7aad Author: Maciej Fijalkowski Date: Sun Jul 19 15:56:07 2026 +0200 xsk: reclaim invalid Tx descriptors in ZC batch path [ Upstream commit 72f2b4516faf55d4dfac2414649d3cffa5fd2c5e ] The zero-copy Tx batch parser stops when it encounters an invalid descriptor. If this happens after one or more continuation descriptors, the Tx consumer can be advanced past fragments that are neither submitted to the driver nor returned to userspace through the completion ring. A similar problem occurs when a packet exceeds xdp_zc_max_segs. The descriptors consumed up to the limit are released without completion, and the remaining continuation descriptors can subsequently be interpreted as the beginning of another packet. Parse Tx batches in packet units and distinguish descriptors belonging to complete valid packets from descriptors consumed while draining an invalid or oversized packet. Return the former to the driver and append the latter to the CQ address area so userspace can reclaim their UMEM frames. Treat a standalone invalid descriptor as a one-descriptor reclaim-only packet. Advancing the Tx-ring consumer releases the ring slot, but does not by itself return ownership of the referenced UMEM frame to userspace. Once draining starts, continue until the packet's end-of-packet descriptor is consumed. Preserve the drain state on the socket when EOP has not yet been supplied, so draining can continue during a later call. Leave incomplete but otherwise valid packets on the Tx ring. Shared-UMEM pools using multi-buffer Tx also need packet-framed parsing. Walk their Tx sockets one packet at a time, preserving the existing per-socket fairness scheme, instead of using the legacy one-descriptor fallback. Keep that fallback for shared pools that do not use multi-buffer Tx. Since the drain state is maintained per socket and both the singular and shared paths can resume an interrupted drain, changing the socket list from singular to shared requires no special bind-time transition. CQ entries are positional, and drivers may complete only part of the Tx work returned by xsk_tx_peek_release_desc_batch(). Therefore, reclaim-only entries cannot be published immediately when earlier driver-visible descriptors are still outstanding. Track the number of driver-visible CQ entries preceding the reclaim entries. Let xsk_tx_completed() publish partial hardware Tx completions, and publish the reclaim entries only after every earlier Tx descriptor has completed. Complete a reclaim-only batch immediately when there is no driver-visible work in front of it, and prevent another Tx batch from being appended while reclaim entries remain pending. Also cap batch processing by the size of the pool's temporary descriptor array, as Tx rings belonging to sockets sharing a UMEM may have different sizes. This ensures that every invalid Tx descriptor consumed by the ZC batch path is either submitted to the driver as part of a valid packet or returned to userspace without violating CQ completion ordering. Reviewed-by: Jason Xing Signed-off-by: Maciej Fijalkowski Acked-by: Stanislav Fomichev Fixes: cf24f5a5feea ("xsk: add support for AF_XDP multi-buffer on Tx path") Link: https://patch.msgid.link/20260719135609.147823-5-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ff789fdfa231e56e74f8c6f0549405817a036d7 Author: Maciej Fijalkowski Date: Sun Jul 19 15:56:06 2026 +0200 xsk: provide sufficient space in pool->tx_descs [ Upstream commit 08c9a8e794b4694c100dafcb80e069e29ad81b64 ] The temporary Tx descriptor array in an XSK buffer pool is currently sized from the Tx ring of the socket that creates the pool. This is insufficient for shared-UMEM Tx. A later socket may have a larger Tx ring and submit a valid multi-buffer packet containing more descriptors than the first socket's ring, while still remaining within the device's xdp_zc_max_segs limit. A packet-framed batch parser bounded by the temporary array cannot reach the end-of-packet descriptor in that case. It leaves the packet on the Tx ring and encounters the same packet on every subsequent attempt, stalling Tx processing for that socket. Size the temporary descriptor array to the larger of the first Tx ring and the device's xdp_zc_max_segs capability. This keeps the array large enough to inspect one maximum-sized valid packet. Larger shared Tx rings do not require further resizing, as they can be processed over multiple batches. Following commit will actually address the data path side. Fixes: d5581966040f ("xsk: support ZC Tx multi-buffer in batch API") Reviewed-by: Jason Xing Signed-off-by: Maciej Fijalkowski Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260719135609.147823-4-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Stable-dep-of: 72f2b4516faf ("xsk: reclaim invalid Tx descriptors in ZC batch path") Signed-off-by: Sasha Levin commit 9990cac513e8b191de2ee589051ea7ebf3cee940 Author: Cen Zhang (Microsoft) Date: Thu Jul 23 00:49:55 2026 -0400 net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds [ Upstream commit aef96eead2860cbfa371e4471d4f04412213b958 ] u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char, 0-255) into the kernel knode object without bounds validation. When a packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates `ntohs(offmask & *data) >> offshift` where the left operand is a 16-bit value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior per C11 6.5.7p3, triggerable by an unprivileged user via user/network namespaces. UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43 shift exponent 32 is too large for 32-bit type int Fix this by rejecting offshift >= 16 during filter creation in u32_change(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: AutonomousCodeSecurity@microsoft.com Link: https://lore.kernel.org/all/20260720034514.23053-1-blbllhy@gmail.com Signed-off-by: Cen Zhang (Microsoft) Acked-by: Jamal Hadi Salim Tested-by: Jamal Hadi Salim Tested-by: Victor Nogueira Link: https://patch.msgid.link/20260723044955.89471-1-blbllhy@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 15ed8a9b7c63e9171f5139a6aaa1ffb61809861f Author: David Howells Date: Mon Jul 27 14:07:15 2026 +0100 netfs: Fix folio_queue ENOMEM in writeback by adding a mempool [ Upstream commit 1d78d56c43ef3768183e8370e7367b162700e049 ] Fix the handling of folio_queue allocation failure in writeback by adding a mempool and passing in gfp_t flags to the rolling buffer functions that allocate memory, using the mempool if gfp != GFP_KERNEL. This is then extended upwards and the gfp to be used for a request is stored in the netfs_io_request struct and is then used for both requests and subrequests, eliminating the sleeping loops there. The failure caused: folio != NULL WARNING: fs/netfs/write_issue.c:603 at netfs_writepages+0x883/0xa10 fs/netfs/write_issue.c:603, CPU#3: syz.0.17/5919 Fixes: cd0277ed0c18 ("netfs: Use new folio_queue data type and iterator instead of xarray iter") Reported-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0da43efa72f88bd3a8af Signed-off-by: David Howells Link: https://patch.msgid.link/20260727130716.1099906-5-dhowells@redhat.com Tested-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com cc: Paulo Alcantara cc: Yun Zhou cc: Matthew Wilcox cc: Christoph Hellwig cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ff5625d27415ace5667bf87ebc16c3a0a98db22f Author: Pauli Virtanen Date: Sat Jul 25 12:59:19 2026 +0300 Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback [ Upstream commit 56e78b670356caab0b607e8aad4cf819a1909d07 ] There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Handle NULL hcon, return 0 + do nothing to match the previous behavior. Fixes: 024421cf3992 ("Bluetooth: hci_conn: Fix not setting timeout for BIG Create Sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ff926f3ef6c80e4edbe3ba0cc4f7eb4f45f52835 Author: Luiz Augusto von Dentz Date: Wed Dec 10 11:38:08 2025 -0500 Bluetooth: hci_conn: Fix using conn->le_{tx,rx}_phy as supported PHYs [ Upstream commit 129d1ef3c5e60d51678e6359beaba85771a49e46 ] conn->le_{tx,rx}_phy is not actually a bitfield as it set by HCI_EV_LE_PHY_UPDATE_COMPLETE it is actually correspond to the current PHY in use not what is supported by the controller, so this introduces different fields (conn->le_{tx,rx}_def_phys) to track what PHYs are supported by the connection. Fixes: eab2404ba798 ("Bluetooth: Add BT_PHY socket option") Signed-off-by: Luiz Augusto von Dentz Adapted for this tree: the all-remote-features event handler does not exist here, so that hunk is dropped, and the LE remote features are kept in conn->features[0] rather than conn->le_features. Stable-dep-of: 56e78b670356 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback") Signed-off-by: Sasha Levin commit 946dc5835c8fbe5eb5ceb13f5717778911ff4586 Author: Kees Cook Date: Mon Nov 3 16:26:10 2025 -0800 net: Convert proto_ops bind() callbacks to use sockaddr_unsized [ Upstream commit 0e50474fa514822e9d990874e554bf8043a201d7 ] Update all struct proto_ops bind() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook Link: https://patch.msgid.link/20251104002617.2752303-2-kees@kernel.org Signed-off-by: Jakub Kicinski [ Adapted for this tree: kept the existing pn_socket_autobind() error handling and only changed the bind cast to sockaddr_unsized; also added the struct sockaddr_unsized definition to include/linux/socket.h, since its introducing commit is not present. ] Stable-dep-of: 56e78b670356 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback") Signed-off-by: Sasha Levin commit f1b4c6aaf7655e1e34c4b83f62a0ce0dd073abde Author: Kriish Sharma Date: Mon Oct 13 01:43:19 2025 +0000 hdlc_ppp: fix potential null pointer in ppp_cp_event logging [ Upstream commit 3dacc900c00bad7275ee8c096dbcaab699d83e36 ] drivers/net/wan/hdlc_ppp.c: In function ‘ppp_cp_event’: drivers/net/wan/hdlc_ppp.c:353:17: warning: ‘%s’ directive argument is null [-Wformat-overflow=] 353 | netdev_info(dev, "%s down\n", proto_name(pid)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wan/hdlc_ppp.c:342:17: warning: ‘%s’ directive argument is null [-Wformat-overflow=] 342 | netdev_info(dev, "%s up\n", proto_name(pid)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Update proto_name() to return "LCP" by default instead of NULL. This change silences the compiler without changing existing behavior and removes the need for the local 'pname' variable in ppp_cp_event. Suggested-by: Krzysztof Hałasa Signed-off-by: Kriish Sharma Acked-by: Krzysztof Hałasa Link: https://patch.msgid.link/20251013014319.1608706-1-kriish.sharma2006@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: 56e78b670356 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback") Signed-off-by: Sasha Levin commit 68ffe4265775ed9e09e18e9a3b388740e25257bf Author: Pauli Virtanen Date: Sat Jul 25 12:59:20 2026 +0300 Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback [ Upstream commit 44fc74069d8988f2825246f9401218e29de2c0ab ] There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Fixes: 6d0417e4e1cf ("Bluetooth: hci_conn: Fix not setting conn_timeout for Broadcast Receiver") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a76243488740a07c81c9adf431685bb7f7c31d8c Author: Hariprasad Kelam Date: Wed Jul 22 13:42:29 2026 +0530 octeontx2-af: Block VFs from clobbering special CGX PKIND state [ Upstream commit 3bd438a58e910db5dc369aa25dfed1fc95f1b596 ] PF and VF NIX LFs that share a CGX LMAC reuse the same hardware PKIND programming. When HiGig2 or EDSA parsing is enabled, a VF NIX LF alloc must not reset the LMAC RX PKIND or default TX parse config over the PF setup. Add cgx_get_pkind() and rvu_cgx_is_pkind_config_permitted() so VFs skip cgx_set_pkind(), rvu_npc_set_pkind(), and NIX_AF_LFX_TX_PARSE_CFG updates when the LMAC is using NPC_RX_HIGIG_PKIND or NPC_RX_EDSA_PKIND. Fixes: 94d942c5fb97 ("octeontx2-af: Config pkind for CGX mapped PFs") Cc: Geetha sowjanya Signed-off-by: Hariprasad Kelam Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260722081229.1653619-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 59adeedebf02aa1c203de1d2b67ec45bfab7a3c6 Author: Harald Freudenberger Date: Thu Jul 23 11:54:53 2026 +0200 s390/zcrypt: Close speculative mem read possibility [ Upstream commit e935cd525af4c6ed2e2c6404aa27ca19c7f39ddb ] The domain value is extracted from a given CCA or EP11 ioctl struct when a CPRB is about to be sent. Thus this is a user controlled value. Under some special conditions (custom device node used, administrative load) this value is used as an array index after bounds checking, but without speculation barrier. Add the missing array_index_nospec() call to prevent speculative execution where this domain value is used. Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices") Cc: stable@vger.kernel.org Reported-by: Christian Borntraeger Reviewed-by: Finn Callies Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 20b0b0159390fa5c00a435195649680fefda81e0 Author: Harald Freudenberger Date: Wed Mar 18 17:41:29 2026 +0100 s390/zcrypt: Rework domain processing within zcrypt device driver [ Upstream commit e2c6d91eb8b1533753755f07803e47eceed263d0 ] Slight rework of the domain handling within the zcrypt dd: Remove this curious construct to give a pointer to the domain field within the CPRB struct to the zcrypt API and later fill in the target domain via this pointer. Now the domain is filled in with the send function when the ready constructed AP message is about to be pushed down into the software queue for AP queue processing. So now the domain handling for CCA, EP11 and (internal) rng CPRBs is the same. With this comes a slight reshuffle of the code related to domain processing in the zcrypt API and the message type 60 protocol implementation code. Reviewed-by: Holger Dengler Signed-off-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik Stable-dep-of: e935cd525af4 ("s390/zcrypt: Close speculative mem read possibility") Signed-off-by: Sasha Levin commit 2a25ddf0bf6dd311598df4b5ddda53139cce0e99 Author: Harald Freudenberger Date: Wed Mar 18 17:41:28 2026 +0100 s390/zcrypt: Move inline function rng_type6cprb_msgx from header to code [ Upstream commit 23a4757d6d699e602b358808359149d0e8be6db9 ] Function rng_type6cprb_msgx() is only used once and thus no need to provide it in header file any more. Move it at the place within the code where it is used. Reviewed-by: Holger Dengler Reviewed-by: Anthony Krowiak Signed-off-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik Stable-dep-of: e935cd525af4 ("s390/zcrypt: Close speculative mem read possibility") Signed-off-by: Sasha Levin commit 23a541c31b45fa813b33269376f6bd53535429a8 Author: George Zhang Date: Thu Jul 16 17:00:01 2026 -0400 drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewport [ Upstream commit f327e389c07cfc3a2f6ff54f6214e1a52d457edc ] If a plane reaches calculate_mcache_setting with a zero-area viewport, calculate_mcache_setting exits early with num_mcaches == 0 and mvmpg_width/height == 0. This will cause a divide-by-zero panic and can also cause an underflow on num_mcaches. Fix this by changing calculate_mcache_setting to bool and adding guards after each calculate_mcache_row_bytes call. If num_mcaches or mvmpg_width/height is zero, return a false. Callers will propagate the failure as a rejected mode, which prevents the panic. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5302 Reviewed-by: Sun peng (Leo) Li Reviewed-by: Dillon Varone Signed-off-by: George Zhang Signed-off-by: Fangzhi Zuo Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 029b363c9b690613141338436ac91366b1928af2 Author: Abd-Alrhman Masalkhi Date: Fri May 1 13:46:50 2026 +0200 md/raid1,raid10: fix error-path detection with md_cloned_bio() [ Upstream commit 811545e0926d02a6a0b1a1258bb5544777c164d4 ] Detect the error path using md_cloned_bio() instead of relying on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be NULL or -1 after splitting and resubmitting a failed bio. As a result, the error path may not be recognized and memory allocations can incorrectly use GFP_NOIO instead of (GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under memory pressure. Fixes: 689389a06ce7 ("md/raid1: simplify handle_read_error().") Fixes: 545250f24809 ("md/raid10: simplify handle_read_error()") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Xiao Ni Link: https://patch.msgid.link/20260501114652.590037-3-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bcf30e14d2bd509c57e93021b46aedc878896e7b Author: Abd-Alrhman Masalkhi Date: Fri May 1 13:46:51 2026 +0200 md/raid1,raid10: fix bio accounting for split md cloned bios [ Upstream commit ba976e3501111d11c550848b3b7341a73035f582 ] Use md_cloned_bio() to control bio accounting instead of relying on r1bio_existed in raid1 or the io_accounting flag in raid10. The previous logic does not reliably reflect whether a bio is an md cloned bio. When a failed bio is split and resubmitted via bio_submit_split_bioset() on the error path, this can lead to either double accounting for md cloned bios, or missing accounting for bios returned from bio_submit_split_bioset() Fix this by using md_cloned_bio() to detect md cloned bios and skip accounting accordingly. Fixes: bb2a9acefaf9 ("md/raid1: switch to use md_account_bio() for io accounting") Fixes: 820455238366 ("md/raid10: switch to use md_account_bio() for io accounting") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Xiao Ni Link: https://patch.msgid.link/20260501114652.590037-4-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit ea2d1d2ebf60b70b602a92261a567d5fc4575eab Author: Abd-Alrhman Masalkhi Date: Fri May 1 13:46:49 2026 +0200 md/raid1,raid10: fix deadlock in read error recovery path [ Upstream commit 7b15c24f805339a585cfe7d72f446b7e88b9bcc0 ] raid1d and raid10d may resubmit a split md cloned bio while handling a read error. In this case, resubmitting the bio can lead to a deadlock if the array is suspended before md_handle_request() acquires an active_io reference via percpu_ref_tryget_live(). Since the cloned bio already holds an active_io reference, trying to acquire another reference via percpu_ref_tryget_live() can lead to a deadlock while the array is suspended. Fix this by using percpu_ref_get() for md cloned bios. Fixes: bb2a9acefaf9 ("md/raid1: switch to use md_account_bio() for io accounting") Fixes: 820455238366 ("md/raid10: switch to use md_account_bio() for io accounting") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Xiao Ni Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260501114652.590037-2-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Stable-dep-of: ba976e350111 ("md/raid1,raid10: fix bio accounting for split md cloned bios") Signed-off-by: Sasha Levin commit e4a59511e1abd4899d1aa60e1ba171558e3add71 Author: Abd-Alrhman Masalkhi Date: Wed Apr 15 16:03:18 2026 +0200 md: replace wait loop with wait_event() in md_handle_request() [ Upstream commit 8e8278ac702e2d5d44211b4b10599aa3b2cb0555 ] The wait loop is equivalent to wait_event() and can be simplified by usaing it for improving readability. Signed-off-by: Abd-Alrhman Masalkhi Link: https://lore.kernel.org/r/20260415140319.376578-2-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Stable-dep-of: ba976e350111 ("md/raid1,raid10: fix bio accounting for split md cloned bios") Signed-off-by: Sasha Levin commit 55c6f05b667726d2da5fd011d646fb48ce5b6b9c Author: Miaoqing Pan Date: Tue May 12 10:11:08 2026 +0800 wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic() [ Upstream commit 98d4f92ab6a1af2ea2ab590d7e2801b203110981 ] In ath12k_wifi7_dp_rx_h_verify_tkip_mic(), the call to ath12k_dp_rx_check_nwifi_hdr_len_valid() may return false when the NWIFI header length is invalid, causing the function to abort early with -EINVAL. When this happens, the error propagates to ath12k_wifi7_dp_rx_h_defrag(), which clears first_frag by setting it to NULL. As a result, the corresponding MSDU is no longer referenced by the defragmentation path and is never freed. This leads to a memory leak for the affected MSDU on this error path. Proper cleanup is required to ensure the MSDU is released when header validation fails during TKIP MIC verification. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 9a0dddfb30f1 ("wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi") Signed-off-by: Miaoqing Pan Reviewed-by: Tamizh Chelvam Raja Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260512021108.2031651-1-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c09314b8b4c6290290a8a59c9e0e546231231186 Author: Wei Zhang Date: Mon May 11 21:49:04 2026 -0700 wifi: ath12k: fix inconsistent arvif state in vdev_create error paths [ Upstream commit c972636efc63f0f43d725b59805dd1ae5bc4b31e ] ath12k_mac_vdev_create() has three error path issues that leave arvif in an inconsistent state: 1. When ath12k_wmi_vdev_create() fails, the function returns directly without clearing arvif->ar, which was already set before the WMI call. Subsequent code checking arvif->ar to determine vdev readiness will see a non-NULL value despite no vdev existing in firmware. 2. When ath12k_wmi_send_peer_delete_cmd() fails in err_peer_del, the code jumped to err: skipping the DP peer cleanup and vdev rollback, leaving num_created_vdevs, vdev maps and arvif list membership live. 3. When ath12k_wait_for_peer_delete_done() fails, the code jumped to err_vdev_del: skipping the DP peer cleanup. Fix by changing the ath12k_wmi_vdev_create() failure to goto err instead of returning directly, routing both err_peer_del failure paths through err_dp_peer_del: for proper DP peer and vdev rollback, and consolidating the arvif state cleanup at err:. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO") Signed-off-by: Wei Zhang Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260512044906.1735821-2-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d94bf50756d7f80bb728ad58246376649e1035b6 Author: Zhang Cen Date: Thu May 28 23:12:30 2026 +0800 ocfs2: validate fast symlink target during inode read [ Upstream commit e234973f286ed2e8961a24561ec91594ec3e3ff8 ] ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Link: https://lore.kernel.org/20260528151230.361127-1-rollkingzzc@gmail.com Fixes: ea022dfb3c2a ("ocfs: simplify symlink handling") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Reviewed-by: Joseph Qi Cc: Gui-Dong Han <2045gemini@gmail.com> Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b4059a1f57eff3e206d44697f64ad81076512760 Author: David Windsor Date: Fri Jun 5 10:57:07 2026 -0400 bpf: Reject sleepable BPF_LSM_CGROUP programs at load time [ Upstream commit 5b038319be442c620f774e6fc9e9283deeca1c75 ] The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should not attach any sleepable BPF programs there. Add support to the verifier to explicitly reject attempts to load sleepable BPF programs destined for LSM cgroup attachment. Without this, we get the following splat from a BPF_LSM_CGROUP program marked BPF_F_SLEEPABLE attached to file_open when it calls bpf_get_dentry_xattr(): BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load preempt_count: 0, expected: 0 RCU nest depth: 2, expected: 0 Call Trace: down_read+0x76/0x480 ext4_xattr_get+0x11f/0x700 __vfs_getxattr+0xf0/0x150 bpf_get_dentry_xattr+0xbb/0xf0 bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85 __cgroup_bpf_run_lsm_current+0x326/0x840 bpf_trampoline_6442534646+0x62/0x14d security_file_open+0x34/0x60 do_dentry_open+0x340/0x1260 vfs_open+0x7a/0x440 path_openat+0x1bac/0x30a0 libbpf provides a .s named section variant for every sleepable program type except lsm_cgroup, reflecting that per-cgroup LSM programs are intended to only run in a non-sleepable context. The above splat was obtained by bypassing libbpf by using bpf(2) directly. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Signed-off-by: David Windsor Acked-by: Yonghong Song Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20260605145707.608579-1-dwindsor@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 68cf46755894d495b432e21f9e25637030d8b075 Author: Bryam Vargas Date: Sat Jun 6 07:43:45 2026 +0000 wifi: mac80211: bound S1G TIM PVB walk to the TIM element [ Upstream commit b224d18b1e5d1cddfc67f63f41d80023b2ec8889 ] ieee80211_s1g_check_tim() parses the S1G Partial Virtual Bitmap (PVB) of a received TIM element. The TIM is handed in as the element payload: ieee802_11_parse_elems_full() stores elems->tim = elem->data and elems->tim_len = elem->datalen (net/mac80211/parse.c), so the valid bytes are [tim, tim + tim_len). When walking the encoded blocks the function passes the walker an end sentinel of (const u8 *)tim + tim_len + 2, i.e. two bytes past the end of the element. ieee80211_s1g_find_target_block() loops while (ptr + 1 <= end) and dereferences ptr (and the per-mode ieee80211_s1g_len_*() helpers read *ptr), so it can read up to two bytes beyond the TIM element -- an out-of-bounds read of adjacent skb/heap data when the TIM is the last element in the frame. The +2 appears to account for the element id/len header, but tim already points past that header at the element payload, so the addend is wrong. Pass the correct element end, (const u8 *)tim + tim_len. Fixes: e0c47c6229c2 ("wifi: mac80211: support parsing S1G TIM PVB") Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260606074341.49135-1-hexlabsecurity@proton.me Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0901d2c89442647c4b7462a3de6c6ee01b33684e Author: Johannes Berg Date: Wed Nov 5 15:36:54 2025 +0100 wifi: ieee80211: split S1G definitions out [ Upstream commit 00105d7600bfb171037783da5f26e2565c7d2106 ] The ieee80211.h file has gotten very long, continue splitting it by putting S1G definitions into a separate file. Link: https://patch.msgid.link/20251105153843.82c0bddee6e3.Ic6646615286dad240b42e31e9d428c7e4ea40ce0@changeid Signed-off-by: Johannes Berg Stable-dep-of: b224d18b1e5d ("wifi: mac80211: bound S1G TIM PVB walk to the TIM element") Signed-off-by: Sasha Levin commit f488b83a38103e8eea442cd8fa1a10f982bd60af Author: Larysa Zaremba Date: Mon May 18 13:15:04 2026 +0200 ixgbe: do not configure xps for XDP queues [ Upstream commit 7bd4355272de34c2e90e34b72c5613736d03c32b ] netif_set_xps_queue() should not be called for an XDP Tx queue, since such queues are not netdev-exposed. On systems with number of CPUs >=64, on E610 adapter, netdev is configured with maximum number queue pairs being 63 (due to MSI-X assignment), but configuring XDP results in 64 XDP queues. So, during XDP program load, when netif_set_xps_queue() is called for the last XDP queue, we get a WARNING with a call trace and KASAN report afterwards (if enabled). [ 2012.699800] WARNING: net/core/dev.c:2854 at __netif_set_xps_queue+0x116a/0x1e40, CPU#36: xdpsock/103668 [...] [ 2012.700029] RIP: 0010:__netif_set_xps_queue+0x116a/0x1e40 [ 2012.700035] Code: b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84 [ 2012.700040] RSP: 0018:ffff8882369aeb28 EFLAGS: 00010246 [ 2012.700046] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 2012.700050] RDX: 1ffff1111da3d891 RSI: ffff888120e34250 RDI: ffff8888ed1ec488 [ 2012.700054] RBP: ffff888913281560 R08: 0000000000000000 R09: ffff8888ed1ec000 [ 2012.700058] R10: ffff8888a2e83180 R11: 0000000000000000 R12: 0000000000007fa8 [ 2012.700061] R13: 000000000000003f R14: ffff888120e34854 R15: ffff8889132817c8 [ 2012.700065] FS: 00007fc8ea9ff740(0000) GS:ffff88884cefe000(0000) knlGS:0000000000000000 [ 2012.700069] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2012.700073] CR2: 00007f81c8000020 CR3: 00000002299f8006 CR4: 00000000007726f0 [ 2012.700077] PKRU: 55555554 [ 2012.700080] Call Trace: [ 2012.700084] [ 2012.700087] ? ktime_get+0x61/0x150 [ 2012.700097] ? usleep_range_state+0x133/0x1b0 [ 2012.700108] ? __pfx_usleep_range_state+0x10/0x10 [ 2012.700114] netif_set_xps_queue+0x31/0x50 [ 2012.700119] ixgbe_configure_tx_ring+0x472/0x920 [ixgbe] [...] [ 2012.700486] ixgbe_xdp+0x38f/0x750 [ixgbe] [...] [ 2012.701094] BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1ac5/0x1e40 [ 2012.701100] Write of size 4 at addr ffff88888d43cff8 by task xdpsock/103668 Skip XPS configuration for XDP Tx queues. Fixes: 33fdc82f0883 ("ixgbe: add support for XDP_TX action") Reviewed-by: Alexander Lobakin Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 29e07ec352f0ad06c833a18bf47d82c81f55544f Author: Yun Zhou Date: Mon Jun 8 23:25:21 2026 +0800 ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT [ Upstream commit c143957520c6c9b5cd72e0de8b52b814f0c576fe ] Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not belong to the same superblock as the original file. Currently, this validation is performed inside ext4_move_extents() by mext_check_validity(), but only after lock_two_nondirectories() has already acquired the inode locks. When the donor fd refers to a file on a different filesystem (e.g., overlayfs), this late validation creates a circular lock dependency: CPU0 (overlayfs write) CPU1 (ext4 ioctl) ---- ---- inode_lock(ovl_inode) mnt_want_write_file(filp) sb_start_write(ext4_sb) [sb_writers] backing_file_write_iter() vfs_iter_write(real_file) file_start_write(real_file) sb_start_write(ext4_sb) [blocked by freeze] lock_two_nondirectories() inode_lock(ovl_inode) [blocked] With a concurrent freeze operation holding sb_writers write side, this forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock. Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files, it fundamentally requires both files to reside on the same ext4 filesystem. Moving the superblock check before any lock acquisition is both semantically correct and eliminates the circular dependency by ensuring that cross-filesystem donor fds are rejected before sb_writers or inode locks are taken. Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base") Reported-by: syzbot+ad6118a7584b607c67f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ad6118a7584b607c67f2 Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20260608152521.1292656-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0bc97a4110e871c9ee9aaf9d756e6cdcd64ce43d Author: Zhang Yi Date: Mon Oct 13 09:51:22 2025 +0800 ext4: add mext_check_validity() to do basic check [ Upstream commit 22218516e462d59b27ffcfc9dd75d4f98e482c51 ] Currently, the basic validation checks during the move extent operation are scattered across __ext4_ioctl() and ext4_move_extents(), which makes the code somewhat disorganized. Introduce a new helper, mext_check_validity(), to handle these checks. This change involves only code relocation without any logical modifications. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Message-ID: <20251013015128.499308-7-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Stable-dep-of: c143957520c6 ("ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT") Signed-off-by: Sasha Levin commit 6166cb1344f16dd403f2192f4bea6f6654f1ae1e Author: Li RongQing Date: Sat May 30 07:28:52 2026 -0400 iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path [ Upstream commit db50fb87015b955a5a0c155293b2dd40d63a3b9e ] In iommu_dma_map_sg(), when handling PCI P2PDMA cases, the DMA length of the current scatterlist segment `s` is incorrectly assigned from the head entry `sg->length` instead of the current entry `s->length`. This typo causes all P2PDMA segments in the scatterlist to inherit the length of the first segment, leading to corrupted DMA lengths for multi- segment scatterlists. Fix this by using `s->length` instead of `sg->length`. Fixes: a25e7962db ("PCI/P2PDMA: Refactor the p2pdma mapping helpers") Signed-off-by: Li RongQing Reviewed-by: Logan Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 98c7e206af48b4433b2192cc1a538db2acc49876 Author: Dan Williams Date: Tue May 19 14:01:54 2026 -0700 cxl/region: Block region delete during region creation [ Upstream commit d91feb88692e81b00cd22f0125cfcd04970b4a0b ] Expand the range lock, rename it "regions_lock", to disable region deletion in the critical period between construct_region() and attach_target(), as well as the period between device_add() and registering the remove actions. Otherwise, userspace can confuse the kernel. It can violate the assumption the region stays registered through the completion of cxl_add_to_region(). It can violate the assumption that devm_add_action_or_reset() is working with a live 'struct cxl_region'. It is ok for the region to disappear outside of those windows as that mirrors device hotplug flows where the proper locks are held. Fixes: a32320b71f08 ("cxl/region: Add region autodiscovery") Signed-off-by: Dan Williams Reviewed-by: Alejandro Lucero Tested-by: ALejandro Lucero Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260519210158.1499795-2-djbw@kernel.org Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 53fb46cf933dc4361c1a72491e247841d0b0fc85 Author: Pablo Neira Ayuso Date: Wed Jun 10 00:03:19 2026 +0200 netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use them [ Upstream commit 2354e975932dabb06fad239f07a3b68fd1809737 ] Update nft_dup and nft_fwd to use the nf_dev_xmit_recursion() helpers. This patch also disables BH when transmitting the skb to address a possible migration to different CPU leading to imbalanced decrementation of the recursion counters. This is modeled after Florian Westphal's dev_xmit_recursion*() API available since commit 97cdcf37b57e ("net: place xmit recursion in softnet data") according to its current state in the tree. Fixes: 1d47b55b36d2 ("netfilter: nft_fwd_netdev: use recursion counter in neigh egress path") Fixes: f37ad9127039 ("netfilter: nf_dup_netdev: Move the recursion counter struct netdev_xmit") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fcacd948b10a351aa128acd3c2c4cee62d1ea677 Author: Weiming Shi Date: Mon Apr 27 14:34:50 2026 +0200 netfilter: nft_fwd_netdev: use recursion counter in neigh egress path [ Upstream commit 1d47b55b36d2ec73fe6901212c8b28a593c3b27c ] nft_fwd_neigh can be used in egress chains (NF_NETDEV_EGRESS). When the forwarding rule targets the same device or two devices forward to each other, neigh_xmit() triggers dev_queue_xmit() which re-enters nf_hook_egress(), causing infinite recursion and stack overflow. Move the nf_get_nf_dup_skb_recursion() accessor and NF_RECURSION_LIMIT to the shared header nf_dup_netdev.h as a static inline, so that nft_fwd_netdev can use the recursion counter directly without exported function call overhead. Guard neigh_xmit() with the same recursion limit already used in nf_do_netdev_egress(). [ Updated to cache the nf_get_nf_dup_skb_recursion pointer. --pablo ] Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 2354e975932d ("netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use them") Signed-off-by: Sasha Levin commit 7d5a0dc8eaab4deff6431cbe4dcc60f290cc3cba Author: Pablo Neira Ayuso Date: Mon Apr 27 14:34:48 2026 +0200 netfilter: nft_fwd_netdev: add device and headroom validate with neigh forwarding [ Upstream commit 0a0b35f0bf10b4c2be607465f5c9c12c8681305b ] The ttl field has been decremented already and evaluation of this rule would proceed, just drop this packet instead if there is no destination device to forwards this packet. This is exactly what nf_dup already does in this case. Moreover, check for headroom and call skb_expand_head() like in the IP output path to ensure there is sufficient headroom when forwarding this via neigh_xmit(). Fixes: d32de98ea70f ("netfilter: nft_fwd_netdev: allow to forward packets via neighbour layer") Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 2354e975932d ("netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use them") Signed-off-by: Sasha Levin commit 33aed3ba04aa56eeeb876935896aa6530c46640e Author: Selvin Xavier Date: Mon Jun 15 15:47:39 2026 -0700 RDMA/bnxt_re: Free CQ toggle page after firmware teardown [ Upstream commit bb45e06f9914ca64ac95341a80a0c20bb8dd46a9 ] Free the toggle page only after firmware teardown completes so that an NQ interrupt arriving during bnxt_qplib_destroy_cq() won't write the toggle value to an already-freed page. Move free_page() after bnxt_qplib_destroy_cq. Fixes: e275919d9669 ("RDMA/bnxt_re: Share a page to expose per CQ info with userspace") Link: https://patch.msgid.link/r/20260615224751.232802-4-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2106c337905d7445d75818e36920b63f9211c584 Author: Selvin Xavier Date: Mon Jun 15 15:47:45 2026 -0700 RDMA/bnxt_re: Add a max slot check for SQ [ Upstream commit dc95931b7e1326dacae547874bf38c092e5960d8 ] The variable WQE mode must be validated against the maximum slots supported by HW. The max supported value is 64K. Adding a max and min check and fail if user supplied value is more than the max supported and zero. Fixes: d8ea645d6984 ("RDMA/bnxt_re: Handle variable WQE support for user applications") Link: https://patch.msgid.link/r/20260615224751.232802-10-selvin.xavier@broadcom.com Reviewed-by: Sriharsha Basavapatna Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b422e3eff0edf0975de4883929adbed28f9d08bc Author: Eric Dumazet Date: Tue Jun 16 14:13:17 2026 +0000 net: serialize netif_running() check in enqueue_to_backlog() [ Upstream commit 46762cefe7f4e5bffc1eb467810a7bbb02e461d7 ] Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped). Fixes: e9e4dd3267d0 ("net: do not process device backlog during unregistration") Reported-by: syzbot+965506b59a2de0b6905c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a315824.b0403584.28d0ff.0000.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Julian Anastasov Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260616141317.407791-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a6916a934277d266728ed334c53d12c4fcbcb70 Author: Eric Dumazet Date: Mon Jan 5 16:30:54 2026 +0000 net: fully inline backlog_unlock_irq_restore() [ Upstream commit 27a01c1969a5d5ed4739e45777957445af96322d ] Some arches (like x86) do not inline spin_unlock_irqrestore(). backlog_unlock_irq_restore() is in RPS/RFS critical path, we prefer using spin_unlock() + local_irq_restore() for optimal performance. Also change backlog_unlock_irq_restore() second argument to avoid a pointless dereference. No difference in net/core/dev.o code size. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260105163054.13698-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 46762cefe7f4 ("net: serialize netif_running() check in enqueue_to_backlog()") Signed-off-by: Sasha Levin commit 459536b3acf137818221d1e69361f0edb32ecc4a Author: Eric Dumazet Date: Fri Oct 24 09:05:17 2025 +0000 net: optimize enqueue_to_backlog() for the fast path [ Upstream commit a086e9860ce6a751acd71dbec54d24a819dd6baa ] Add likely() and unlikely() clauses for the common cases: Device is running. Queue is not full. Queue is less than half capacity. Add max_backlog parameter to skb_flow_limit() to avoid a second READ_ONCE(net_hotdata.max_backlog). skb_flow_limit() does not need the backlog_lock protection, and can be called before we acquire the lock, for even better resistance to attacks. Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251024090517.3289181-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 46762cefe7f4 ("net: serialize netif_running() check in enqueue_to_backlog()") Signed-off-by: Sasha Levin commit 580896e33003845de66c75cd61544cf9d9bfbe15 Author: Helen Koike Date: Wed May 6 14:08:22 2026 -0300 fs/ntfs3: call _ntfs_bad_inode() when failing to rename [ Upstream commit e8ed78f40eecd0176fda71d673f6957c98e7ffbe ] It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce ("fs/ntfs3: Exclude call make_bad_inode for live nodes.") The WARN_ON was added when it wasn't safe by: commit d99208b91933 ("fs/ntfs3: cancle set bad inode after removing name fails") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode. Reported-by: syzbot+4d8e30dbafb5c1260479@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4d8e30dbafb5c1260479 Fixes: 519b078998ce ("fs/ntfs3: Exclude call make_bad_inode for live nodes.") Signed-off-by: Helen Koike Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit da6675b39351609feb9ce93a8f057a303e485dd3 Author: Konstantin Komarov Date: Mon Sep 1 12:00:43 2025 +0300 fs/ntfs3: Reformat code and update terminology [ Upstream commit a846cd0d0a05364c6fa5c4988e75d3b639d6dae5 ] Reformatted the driver code according to the current .clang-format rules and updated description of used terminology. No functional changes intended. Signed-off-by: Konstantin Komarov Stable-dep-of: e8ed78f40eec ("fs/ntfs3: call _ntfs_bad_inode() when failing to rename") Signed-off-by: Sasha Levin commit 308d7951ca221e8c8896b563c4e98d28a4400f2e Author: Adrian Hunter Date: Fri Jun 12 11:01:01 2026 +0300 i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev() [ Upstream commit 650716f23eac488c6696babdc7805f6a6b7427ad ] i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()). Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers. Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260612080107.11606-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7a450460687919e79b5f8503bdeb13ecf4cca311 Author: Abd-Alrhman Masalkhi Date: Sat Jun 13 18:28:07 2026 +0000 md/raid1: fix writes_pending and barrier reference leaks on write failures [ Upstream commit 8e065a1602511282fc0da2dc89445e0eb71a681c ] raid1_make_request() acquires a writes_pending reference with md_write_start() before calling raid1_write_request(). Several failure paths in raid1_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid1_write_request() return a status indicating whether the write request was successfully queued. This allows raid1_make_request() to call md_write_end() when raid1_write_request() fails. Additionally, if wait_blocked_rdev() fails after wait_barrier() succeeds, the associated barrier reference is not released. Call allow_barrier() before returning from that path to keep the barrier accounting balanced. Fixes: b1a7ad8b5c4f ("md/raid1: Handle bio_split() errors") Fixes: f2a38abf5f1c ("md/raid1: Atomic write support") Fixes: 5aa705039c4f ("md: raid1 add nowait support") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260611083514.754922-1-abd.masalkhi@gmail.com?part=1 Closes: https://sashiko.dev/#/patchset/20260611132500.763528-1-abd.masalkhi@gmail.com?part=1 Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260613182810.1317258-2-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit c642583adc136d4c70ce3c65c3f43e847d26c776 Author: Abd-Alrhman Masalkhi Date: Sat Jun 13 18:28:08 2026 +0000 md/raid10: fix writes_pending leak on write request failures [ Upstream commit e045d6ed33f8faa3e3dd6dc33c62ec01e3ad275d ] raid10_make_request() acquires a writes_pending reference with md_write_start() before dispatching write requests. Several failure paths in raid10_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid10_write_request() return a status indicating whether the write request was successfully queued. This allows raid10_make_request() to release the writes_pending reference with md_write_end() when a write request fails. Fixes: 4cf58d952909 ("md/raid10: Handle bio_split() errors") Fixes: c9aa889b035f ("md: raid10 add nowait support") Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260613182810.1317258-3-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 453f4f1e90de55b6bc297936031b68bef93f2e28 Author: Yiyang Chen Date: Thu Jun 18 10:18:43 2026 +0000 bpf: Guard conntrack opts error writes [ Upstream commit 6f6183a39533d727deaa5061cadae6dd9e6744d0 ] The conntrack lookup and allocation kfuncs take an opts pointer together with an opts__sz argument. The verifier checks only the memory range described by opts__sz, but the wrappers unconditionally write opts->error whenever the internal lookup or allocation helper returns an error. For an invalid size smaller than the end of opts->error, that write can land outside the verifier-checked range. Keep returning NULL for invalid arguments, but only report the error through opts->error when the supplied size includes the field. This preserves error reporting for the supported 12-byte and 16-byte layouts, and for other invalid sizes that still include opts->error. Fixes: b4c2b9593a1c ("net/netfilter: Add unstable CT lookup helpers for XDP and TC-BPF") Fixes: d7e79c97c00c ("net: netfilter: Add kfuncs to allocate and insert CT") Signed-off-by: Yiyang Chen Link: https://lore.kernel.org/r/9535e781fe14449b1d4e9bbc3baa7566a93bf512.1781765747.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 644b4c05bd1a4e372b2b653fed90e9085d8cc55e Author: Puranjay Mohan Date: Fri Jan 2 10:00:29 2026 -0800 bpf: net: netfilter: drop dead NULL checks [ Upstream commit bddaf9adda72447061a52b328c2d4c64b327fa30 ] bpf_xdp_ct_lookup() and bpf_skb_ct_lookup() receive bpf_tuple and opts parameter that are expected to be not NULL for real usages (see doc string above functions). They return an error if NULL is passed for opts or tuple. The verifier will now reject programs that pass NULL to these parameters, the kfuns can assume that these are always valid pointer, so drop the NULL checks for these parameters. Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260102180038.2708325-4-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Stable-dep-of: 6f6183a39533 ("bpf: Guard conntrack opts error writes") Signed-off-by: Sasha Levin commit 3827ff67f9fbecd1086e33d23693ef6a1a9c6c38 Author: Eric Dumazet Date: Tue Jun 23 17:30:29 2026 +0000 tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy() [ Upstream commit 7116764ca53ff529335d7ab7c364a69f094b23a5 ] TIPC UDP media bearer teardown calls dst_cache_destroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters) to finish: static void cleanup_bearer(struct work_struct *work) { ... list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) { dst_cache_destroy(&rcast->dst_cache); list_del_rcu(&rcast->list); kfree_rcu(rcast, rcu); } ... dst_cache_destroy(&ub->rcast.dst_cache); udp_tunnel_sock_release(ub->sk); synchronize_net(); ... } This is highly buggy because dst_cache_destroy() immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any synchronization. If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another CPU under RCU protection, it can call dst_cache_get() concurrently, leading to: 1. Use-After-Free on the per-CPU cache pointer itself (crash). 2. "rcuref - imbalanced put()" warning if it attempts to release a dst that was concurrently released by dst_cache_destroy(). Furthermore, calling kfree(ub) immediately after synchronize_net() without closing the socket first (or waiting after closing it) leaves a window where a concurrent receiver (tipc_udp_recv()) could start after synchronize_net(), access ub, and suffer a UAF when kfree(ub) runs. To fix this, we must defer dst_cache_destroy() and kfree(ub) until after we have ensured that no more readers can see the bearer/socket and all existing readers have finished: 1. Defer rcast entry destruction (both dst_cache_destroy() and kfree()) to an RCU callback using call_rcu_hurry(). Using call_rcu_hurry() ensures the dst entries are released quickly. 2. Release the bearer socket using udp_tunnel_sock_release() (stops new receive readers). 3. Call synchronize_net() to wait for all outstanding RCU readers (both transmit and receive) to finish. 4. Now that it is safe, call dst_cache_destroy() on the main bearer cache, and free ub. Note: 3) and 4) can be changed later in net-next to also use call_rcu_hurry() and get rid of the synchronize_net() latency. Fixes: e9c1a793210f ("tipc: add dst_cache support for udp media") Reported-by: syzbot+e14bc5d4942756023b77@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a396a66.52ae72c2.136ac7.0003.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Jon Maloy Cc: tipc-discussion@lists.sourceforge.net Reviewed-by: Xin Long Link: https://patch.msgid.link/20260623173030.2925059-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9de9e8f279de0c299631f530de66c51642eef50a Author: Boris Brezillon Date: Thu Jun 25 14:40:27 2026 +0200 drm/panthor: Always use the IRQ-safe variant when acquiring the fence lock [ Upstream commit 778c57d624974e64535ef1c9d9b4d8e5066153f4 ] Since dma_fence objects can be shared with other subsystems, they may be accessed from hardirq context in those drivers, and we have to take that into account by also using the IRQ-safe variant when acquiring the lock. While at it, switch to the guard model. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=11 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-1-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit bc8f2d1c6f7cf6e6551c00eb582baf4b52a04794 Author: Michael Bommarito Date: Tue Jun 16 21:41:49 2026 -0400 xen/pvcalls: bound backend response req_id before indexing rsp[] [ Upstream commit d33846c8dcc06b83b7acdeac1e8bfbb5c0c26cb2 ] pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends. A backend that sends an out-of-range req_id has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenvif_fatal_tx_err()). The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments). Fixes: 2195046bfd69 ("xen/pvcalls: implement socket command and handle events") Suggested-by: Juergen Gross Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260617014149.2647404-1-michael.bommarito@gmail.com> Signed-off-by: Sasha Levin commit 177d22d31a4ebf13964a4154035ade385382aced Author: Fengnan Chang Date: Fri Jun 12 12:40:41 2026 +0800 iomap: release pages on atomic dio size mismatch [ Upstream commit 681e452683b69a8e1a571cba0f238f8ceacf55d2 ] If bio_iov_iter_get_pages() or the bounce helper succeeds but builds a short bio, the REQ_ATOMIC size check rejects it before submission. The old error path only dropped the bio reference, leaving any pages already attached to the bio unreleased. Release or unbounce the pages before falling through to out_put_bio on this error path. This bug was reported by sashiko: https://sashiko.dev/#/patchset/20260608073134.95964-1-changfengnan%40bytedance.com Fixes: 9e0933c21c12 ("fs: iomap: Atomic write support") Signed-off-by: Fengnan Chang Link: https://patch.msgid.link/20260612044041.10677-1-changfengnan@bytedance.com Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0be672071d6e8c4d3be6a8f796d8e47198763770 Author: Shay Drory Date: Tue Jun 30 14:29:15 2026 +0300 net/mlx5: LAG, Fix off-by-one in single-FDB error rollback [ Upstream commit 0f0e4ae6975c773f7854fc48932a267f6c79088f ] On failure at index i, the reverse cleanup loop in mlx5_lag_create_single_fdb() starts from i, so the failed index itself is rolled back. That can operate on uninitialized state or double-tear-down a rule the add_one path already self-rolled-back. Start the rollback from i - 1 so only successfully-installed entries are undone. Fixes: ddbb5ddc43ad ("net/mlx5: LAG, Refactor lag logic") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630112917.698313-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 31cc289d5b179a37be439043306f518376a58187 Author: Cen Zhang Date: Wed Jun 24 00:12:29 2026 +0800 Bluetooth: 6lowpan: avoid untracked enable work [ Upstream commit 352a59dc1f4a41314b6f827c17e16af7ca88271a ] lowpan_enable_set() allocates a temporary work item and schedules do_enable_set() on system_wq, then returns to debugfs. The debugfs active operation has ended at that point, but the worker still executes module text and manipulates enable_6lowpan and listen_chan. bt_6lowpan_exit() removes the debugfs files and immediately closes and puts listen_chan. It has no pointer to the queued work item, so it cannot cancel or flush it before tearing down the state that the worker uses. The buggy scenario involves two paths, with each column showing the order within that path: debugfs enable write module exit 1. lowpan_enable_set() allocates 1. bt_6lowpan_exit() removes set_enable work the debugfs file 2. schedule_work() queues 2. bt_6lowpan_exit() closes do_enable_set() and puts listen_chan 3. the write operation returns 3. module teardown can continue 4. do_enable_set() later runs against stale state Run the enable state transition synchronously in lowpan_enable_set() instead. The simple debugfs setter can sleep, and this file already handles the 6LoWPAN control write synchronously under the same set_lock. Once the setter returns, debugfs removal covers the whole operation and exit can no longer race with an untracked work item. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in do_enable_set+0x113/0x2e0 Workqueue: events do_enable_set [bluetooth_6lowpan] The buggy address belongs to the object at ffff888109cb8000 Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3dd12422653ad4bbbebe33c49c67dba4c653c804 Author: Lizhi Hou Date: Mon Jun 8 18:12:42 2026 -0700 accel/amdxdna: Fix VMA access race [ Upstream commit 1ba02717e821cf14ece642273958647e79698d3d ] aie2_populate_range() and amdxdna_umap_release() access a saved VMA pointer that may have already been freed, leading to a potential use-after-free. Remove the VMA accesses from these functions to avoid the race. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260609011242.2833740-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 33819cca7b76d5c2385c054f054c4b672ab989d5 Author: Max Zhen Date: Fri Mar 20 14:06:14 2026 -0700 accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval [ Upstream commit d76856beb4a4a6c42244054cd780c00f2d33de4e ] Refactor amdxdna GEM buffer object (BO) handling to simplify address management and unify BO type semantics. Introduce helper APIs to retrieve commonly used BO addresses: - User virtual address (UVA) - Kernel virtual address (KVA) - Device address (IOVA/PA) These helpers centralize address lookup logic and avoid duplicating BO-specific handling across submission and execution paths. This also improves readability and reduces the risk of inconsistent address handling in future changes. As part of the refactor: - Rename SHMEM BO type to SHARE to better reflect its usage. - Merge CMD BO handling into SHARE, removing special-case logic for command buffers. - Consolidate BO type handling paths to reduce code duplication and simplify maintenance. No functional change is intended. The refactor prepares the driver for future enhancements by providing a cleaner abstraction for BO address management. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260320210615.1973016-1-lizhi.hou@amd.com Only the user-mapping bookkeeping part of the refactor is carried here: umap_release() resets the cached user address once the last mapping is gone, and hmm_register() records it when the first mapping is added, both under notifier_lock. The remaining address-helper, BO type and UAPI changes are not needed by the follow-up fix and are dropped. Stable-dep-of: 1ba02717e821 ("accel/amdxdna: Fix VMA access race") Signed-off-by: Sasha Levin commit bf63433873a062a475372a0d32e05f2a9b542d8e Author: Lizhi Hou Date: Thu Feb 26 16:48:41 2026 -0800 accel/amdxdna: Fill invalid payload for failed command [ Upstream commit 89ff45359abbf9d8d3c4aa3f5a57ed0be82b5a12 ] Newer userspace applications may read the payload of a failed command to obtain detailed error information. However, the driver and old firmware versions may not support returning advanced error information. In this case, initialize the command payload with an invalid value so userspace can detect that no detailed error information is available. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260227004841.3080241-1-lizhi.hou@amd.com Stable-dep-of: 1ba02717e821 ("accel/amdxdna: Fix VMA access race") Signed-off-by: Sasha Levin commit 08ff33dce6f91510bb296a753a232db0ca3fd3d8 Author: Yuho Choi Date: Wed Jul 1 00:08:47 2026 -0400 net/liquidio: drop cached VF pci_dev LUT [ Upstream commit 5c0e3ba4f500fd4314ceb42f07f16bc445156431 ] The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup. Fixes: ca6139ffc67ee ("liquidio CN23XX: sysfs VF config support") Fixes: 8c978d059224 ("liquidio CN23XX: Mailbox support") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260701040847.1897845-1-dbgh9129@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 241cf3b7455bebbe492b9df4912b48e3260061d4 Author: Doruk Tan Ozturk Date: Mon Jul 13 19:30:28 2026 +0200 accel/amdxdna: reject user command submission without a command BO [ Upstream commit 261c1fe3327ad24508f54552c6366e3e4db82c15 ] amdxdna_drm_submit_execbuf() passes the user-supplied command BO handle straight into amdxdna_cmd_submit() with drv_cmd == NULL. When the handle is AMDXDNA_INVALID_BO_HANDLE (0), the block that fetches job->cmd_bo is skipped, leaving it NULL, and no check rejects it on the user path (the !job->cmd_bo guard lives inside the != INVALID branch). The job is then armed and pushed to the DRM scheduler. aie2_sched_job_run() takes the drv_cmd == NULL path and calls amdxdna_cmd_set_state(job->cmd_bo) -> amdxdna_gem_vmap(NULL) -> to_gobj(NULL)->dev, a NULL pointer dereference in the drm_sched worker. A process with access to the accel node on a system with a probed AMD NPU can trigger a kernel oops with a single AMDXDNA_EXEC_CMD ioctl (cmd_handles = 0). Only internal driver commands (SYNC_DEBUG_BO / ATTACH_DEBUG_BO) legitimately pass AMDXDNA_INVALID_BO_HANDLE, and they always set drv_cmd. Reject the invalid handle for user submissions (drv_cmd == NULL) at the submit choke point so every user path is covered. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Cc: stable@vger.kernel.org Found by 0sec automated security-research tooling (https://0sec.ai). Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260713173030.87541-2-doruk@0sec.ai Signed-off-by: Sasha Levin commit 0a2c89d538fd4fca07c6ebe4fe03cc932f962441 Author: Bryam Vargas Date: Fri Jun 19 21:54:02 2026 -0500 ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD [ Upstream commit 462775c620197adaabc983ce847e5b9878ff4cb0 ] The PNY CS900 1TB SSD (Phison PS3111-S11, DRAM-less) drops off the bus after entering Device-Initiated Slumber during idle. With the default med_power_with_dipm policy the link goes down (SStatus 1 SControl 300) and does not recover, forcing the filesystem read-only. Forcing max_performance keeps the link stable across prolonged idle. Add a NOLPM quirk so link power management is disabled for this drive specifically, leaving it intact for other devices on the host. Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 4739b1b833cf2f337a4ebb7c2e6312a4d2150382 Author: Niklas Cassel Date: Mon Nov 24 17:34:34 2025 +0100 ata: libata-core: Disable LPM on Silicon Motion MD619{H,G}XCLDE3TC [ Upstream commit 6ce0dd9f54ea9773c0aedfaab7b858fc68a848ba ] According to a user report, the Silicon Motion MD619HXCLDE3TC SSD and the Silicon Motion MD619GXCLDE3TC SSD have problems with LPM. Reported-by: Yihang Li Closes: https://lore.kernel.org/linux-ide/20251121073502.3388239-1-liyihang9@h-partners.com/ Signed-off-by: Niklas Cassel Stable-dep-of: 462775c62019 ("ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD") Signed-off-by: Sasha Levin commit 1c3d9c6bd5b795f3b952b40d574c8e424e14a39b Author: Zhao Li Date: Fri Jun 12 00:19:45 2026 +0800 wifi: mac80211: validate extension-frame layout before RX [ Upstream commit 57d503ce32eccfa7650065ca4c560f7e29a2e676 ] Extension frames only have the extension header at the regular 802.11 header offset. The generic RX path can still reach helpers and interface dispatch code that read regular header address fields before unsupported extension subtypes are dropped. mac80211 currently only handles S1G beacon extension frames. Drop other extension subtypes before they can reach regular-header RX processing. For S1G beacons, linearize the SKB with the management-frame path and require the fixed S1G beacon header, including optional fixed fields indicated by frame control, before generic RX dispatch. Route S1G beacons through the station/default-link RX path without regular-header station lookup. Avoid regular-header address reads in the mac80211 RX paths that process S1G extension beacons, including accept-frame, duplicate-detection, address-copy, and MLO address-translation paths. Also make ieee80211_get_bssid() length-safe before returning the S1G source-address pointer. Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons") Cc: stable@vger.kernel.org Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260611161943.91069-5-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9cbad9c8125f5fe377c0800ab08f7196eab44456 Author: Jamal Hadi Salim Date: Mon Jul 6 20:56:08 2026 +0200 net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains [ Upstream commit ec48b3be2c8595dd290be883dbd4fb8b2f9f5d5e ] When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before. Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper") Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Signed-off-by: Daniel Borkmann Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260706185609.330006-3-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c59a693fbd213f8f27942509b48b1a4111fdd40d Author: Honglei Huang Date: Thu Jun 25 16:23:47 2026 +0800 drm/amd/display: use kvzalloc to allocate struct dc [ Upstream commit 75050390151a14802be433c3856ddcb483cecd24 ] struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL ("hw_init of IP block failed -22"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5406 Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Honglei Huang Signed-off-by: Alex Deucher (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c2ddd180bbee766cf7359473d623423ea9485d93 Author: Cen Zhang Date: Mon Jul 6 23:24:18 2026 +0800 wifi: cfg80211: use wiphy work for socket owner autodisconnect [ Upstream commit 0c2ed186bbe14304415476d6707b747dddcd8583 ] nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev. Fixes: bd2522b16884 ("cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT") Suggested-by: Johannes Berg Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260706152418.779226-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 01f8a354497ba739f81b691b3702bc4c46500a4d Author: Matt Bobrowski Date: Thu Jul 9 02:53:16 2026 +0000 bpf: Fix UAF in sock clone early bailouts [ Upstream commit 7cbd0c4cebe4c9f678d15e6b9ba975e1155a107f ] Similar to recent commit 9b51a6155d14 ("bpf,fork: wipe ->bpf_storage before bailouts that access it"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone(). Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage") Fixes: f12dd75959b0 ("bpf: net: Set sk_bpf_storage back to NULL for cloned sk") Signed-off-by: Matt Bobrowski Signed-off-by: Daniel Borkmann Reviewed-by: Kuniyuki Iwashima Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260709025316.999913-1-mattbobrowski@google.com Signed-off-by: Sasha Levin commit 0b2c44363432a07b7cedd73ed66e9d08a15cb4cb Author: Fushuai Wang Date: Tue Oct 7 15:40:11 2025 +0800 bpf: Use rcu_read_lock_dont_migrate in bpf_sk_storage.c [ Upstream commit 0db4941d9dae159d887e7e2eac7e54e60c3aac87 ] Use rcu_read_lock_dont_migrate() and rcu_read_unlock_migrate() in bpf_sk_storage.c to obtain better performance when PREEMPT_RCU is not enabled. Signed-off-by: Fushuai Wang Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20251007074011.12916-1-wangfushuai@baidu.com Stable-dep-of: 7cbd0c4cebe4 ("bpf: Fix UAF in sock clone early bailouts") Signed-off-by: Sasha Levin commit 88c38ff74f8345fcf8852549f94025754019b037 Author: Arvind Yadav Date: Tue Jul 14 12:14:02 2026 +0530 drm/xe/guc: Keep scheduler timeline name alive [ Upstream commit 299bc6d50b1bed7d1f408391736712f01a0855e2 ] The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. Fixes: 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access rules") Cc: Thomas Hellström Cc: Rodrigo Vivi Cc: Himal Prasad Ghimiray Cc: Matthew Brost Signed-off-by: Arvind Yadav Reviewed-by: Tvrtko Ursulin Acked-by: Matthew Brost Link: https://patch.msgid.link/20260714064402.2457257-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 81f70f130eff985fb678d8b891c960381bc7e900 Author: Arvind Yadav Date: Thu Jul 16 11:56:24 2026 +0530 drm/xe/guc: Hold device ref until queue teardown completes [ Upstream commit 9b7e60184f4b22e893d4ae95234d5f26261a430c ] GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. Fixes: 2d2be279f1ca ("drm/xe: fix UAF around queue destruction") Cc: Thomas Hellström Cc: Rodrigo Vivi Cc: Himal Prasad Ghimiray Cc: Tejas Upadhyay Reviewed-by: Matthew Brost Signed-off-by: Arvind Yadav Link: https://patch.msgid.link/20260716062624.211396-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 8549ac21ab503fc7a40bfa8e6beb69e6320d9877 Author: Ruoyu Wang Date: Sun Jul 12 00:37:16 2026 +0800 bnxt_en: Handle partially initialized auxiliary devices [ Upstream commit 1cb8553c02e93e5a150cebd42f9ee3db0ece4707 ] bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 194fad5b2781 ("bnxt_en: Refactor bnxt_rdma_aux_device_init/uninit functions") Signed-off-by: Ruoyu Wang Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260711163716.3996929-1-ruoyuw560@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e611403f3092834272e5c9eeb596c368e108b8c1 Author: Pavan Chebbi Date: Sat Mar 14 08:16:02 2026 -0700 fwctl/bnxt_en: Refactor aux bus functions to be more generic [ Upstream commit 2c7c85c8c7881d57c5fa1114f4b0dbd7fc53a36f ] Up until now there was only one auxiliary device that bnxt created and that was for RoCE driver. bnxt fwctl is also going to use an aux bus device that bnxt should create. This requires some nomenclature changes and refactoring of the existing bnxt aux dev functions. Convert 'aux_priv' and 'edev' members of struct bnxt into arrays where each element contains supported auxbus device's data. Move struct bnxt_aux_priv from bnxt.h to ulp.h because that is where it belongs. Make aux bus init/uninit/add/del functions more generic which will loop through all the aux device types. Make bnxt_ulp_start/stop functions (the only other common functions applicable to any aux device) loop through the aux devices to update their config and states. Make callers of bnxt_ulp_start() call it only when there are no errors. Also, as an improvement in code, bnxt_register_dev() can skip unnecessary dereferencing of edev from bp, instead use the edev pointer from the function parameter. Future patches will reuse these functions to add an aux bus device for fwctl. Link: https://patch.msgid.link/r/20260314151605.932749-3-pavan.chebbi@broadcom.com Reviewed-by: Andy Gospodarek Reviewed-by: Leon Romanovsky Signed-off-by: Pavan Chebbi Signed-off-by: Jason Gunthorpe Stable-dep-of: 1cb8553c02e9 ("bnxt_en: Handle partially initialized auxiliary devices") Signed-off-by: Sasha Levin commit 5d3cea7d41dc72073fea6f879815c9b57c3b330d Author: Weiming Shi Date: Wed Jul 15 19:52:04 2026 -0700 tipc: serialize udp bearer replicast list updates [ Upstream commit 350e592ff4e30e48ffb55e142d11a73e63f4869c ] tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions. Fixes: ef20cd4dd163 ("tipc: introduce UDP replicast") Reported-by: Xiang Mei Suggested-by: Tung Nguyen Signed-off-by: Weiming Shi Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260716025203.9332-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6089f561e2c31a3ba52836c75c7d2ab50d2eea41 Author: Frank Sorenson Date: Tue Jul 21 18:55:52 2026 -0500 cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths [ Upstream commit c2f2e83e3bbc5483730fd4ee903182761f1ae50f ] In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally. Fixes: e3fc065682eb ("cifs: Deferred close performance improvements") Signed-off-by: Frank Sorenson Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 984ce52ea0e014dcb356e64f69c422529e614ea0 Author: Frank Sorenson Date: Tue Jul 21 18:55:51 2026 -0500 cifs: prevent readdir from changing file size due to stale directory metadata [ Upstream commit e8a8d54c2d508891c142a928fc7d298c4c8bd0dd ] Windows Server's directory enumeration metadata lags behind the actual file size after a write+close or rename. A concurrent readdir() in the window between close() returning to userspace and stat() being called overwrites the correct cached i_size with the stale server value, causing stat() to return the wrong size. Once _cifsFileInfo_put() removes the last writable handle from openFileList, is_size_safe_to_change() permits readdir to overwrite i_size. smb2_close_getattr() then stamps cifs_i->time = jiffies, making the corrupt cached value appear fresh to the next stat(). The existing check (see Fixes:) only blocked stale size updates while an active RW lease was held, not after the last writable handle closes. Add cifsInodeInfo->time_last_write, written via smp_store_release() at writable close and on setattr/truncate. is_size_safe_to_change() checks is_inode_writable() first (acquiring open_file_lock), then rejects a readdir size update if time_last_write falls within acregmax jiffies. The spinlock release in _cifsFileInfo_put() forms a store-release barrier that pairs with the spin_lock() (load-acquire) in is_inode_writable(), ensuring the subsequent smp_load_acquire() on time_last_write observes any update from a concurrent close(). When a size update is rejected and the server value differs from the cached one, cifs_i->time is cleared to force a fresh QUERY_INFO on the next stat(). readdir is also blocked from changing i_size while writable handles are open or an RW lease is held, even on direct-IO mounts. For deferred close (closetimeo > 0), time_last_write is refreshed at the actual server close in smb2_deferred_work_close() and in the cifs_close_deferred_file*() drain paths invoked by lease/oplock breaks and tcon teardown, anchoring the protection window to the real close time rather than the earlier userspace close. time_last_write == 0 skips the time_before() check to avoid false positives near boot on 32-bit systems where jiffies starts close to INITIAL_JIFFIES. Does not reproduce against Samba or with actimeo=0. Fixes: e4b61f3b1c67 ("cifs: prevent updating file size from server if we have a read/write lease") Signed-off-by: Frank Sorenson Signed-off-by: Steve French Stable-dep-of: c2f2e83e3bbc ("cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths") Signed-off-by: Sasha Levin commit 0c07e046e639160a1597830c4c5615ee2a4a5ed5 Author: Satyanarayana K V P Date: Tue Jul 21 10:52:14 2026 +0530 drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers [ Upstream commit 4c92afb4c143526d340545ca581e88e6952ea511 ] CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe] xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe] xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm] ttm_bo_release+0x29e/0x2d0 [ttm] ttm_bo_fini+0x39/0x70 [ttm] xe_gem_object_free+0x1f/0x30 [xe] drm_gem_object_free+0x1d/0x40 ttm_bo_vm_close+0x5f/0x90 [ttm] remove_vma+0x2c/0x70 tear_down_vmas+0x63/0xf0 exit_mmap+0x20d/0x3f0 __mmput+0x45/0x170 mmput+0x31/0x40 do_exit+0x2ba/0xac0 do_group_exit+0x2d/0xb0 __x64_sys_exit_group+0x18/0x20 x64_sys_call+0x14a0/0x2390 do_syscall_64+0xdd/0x640 ? count_memcg_events+0xea/0x240 ? handle_mm_fault+0x1ec/0x2f0 Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P Cc: Matthew Brost Cc: Michal Wajdeczko Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260721052215.2267228-2-satyanarayana.k.v.p@intel.com (cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 16656c3d734693be3d8a36dbf9d09142b69f3ddc Author: Nicholas Dudar Date: Thu Jul 23 22:27:35 2026 +0800 LoongArch: BPF: Zero-extend signed ALU32 div/mod results [ Upstream commit dacd348b8a993373576fe2ee2d8b114740ba57a6 ] ALU32 operations write a 32-bit result and leave the upper 32 bits of the BPF register zero. The LoongArch JIT sign-extends the result of signed ALU32 BPF_DIV and BPF_MOD (off=1), so a negative 32-bit quotient or remainder leaves bits 63:32 set in JITted code while the verifier and interpreter model those bits as zero. Keep sign-extension on the operands, which signed divide needs, and zero-extend the ALU32 result after the divide or modulo instruction, matching the unsigned ALU32 div/mod paths and every other ALU32 operation in this JIT. Fixes: 2425c9e002d2 ("LoongArch: BPF: Support signed div instructions") Fixes: 7b6b13d32965 ("LoongArch: BPF: Support signed mod instructions") Assisted-by: Claude:claude-opus-4-8 Acked-by: Tiezhu Yang Tested-by: Tiezhu Yang Signed-off-by: Nicholas Dudar Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 08fffd2881e2804d55bc74f178e2843e8832b396 Author: Emil Tantilov Date: Fri Jul 17 11:53:34 2026 -0700 idpf: fix max_vport related crash on allocation error during init [ Upstream commit 237f1f7653b8729169af11fae79f01b90d00b87e ] Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb Fixes: 0fe45467a104 ("idpf: add create vport and netdev configuration") Reviewed-by: Madhu Chittim Signed-off-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-13-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c174969f6af6c22fc9c51aefcdb7f9183c3a329a Author: Joonas Lahtinen Date: Wed Jul 1 14:45:13 2026 +0300 drm/i915/gt: Fix NULL deref on sched_engine alloc failure [ Upstream commit 82ec992c404c3dc774c5e9f3d4aa858e97187675 ] Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: 3e28d37146db ("drm/i915: Move priolist to new i915_sched_engine object") Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: # v5.15+ Signed-off-by: Joonas Lahtinen Reviewed-by: Andi Shyti Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260701114513.221254-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit f7e744bac9a720740a60d19319e8e5ed5e5c3c76 Author: Harish Kasiviswanathan Date: Fri Jun 26 12:21:54 2026 -0400 drm/amdgpu: Fix kernel panic during driver load failure [ Upstream commit a279bd143b3c184358b658e43a057e31ee8c4de5 ] Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Signed-off-by: Harish Kasiviswanathan Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit cfb5a56c218888f9d74165dff0c282cd0be97983 Author: Namjae Jeon Date: Sun Jun 7 20:15:51 2026 +0900 ksmbd: prevent path traversal bypass by restricting caseless retry [ Upstream commit 54bab9ba5a9f156ffa9324fcbe5a356fd0242f95 ] ksmbd_vfs_path_lookup() enforces LOOKUP_BENEATH to restrict path resolution within the share root. When a crafted path attempts to escape the share boundary using parent-directory components ('..'), vfs_path_parent_lookup() detects this and immediately fails, returning -EXDEV. However, a bug exists in __ksmbd_vfs_kern_path() under caseless mode. The function fails to intercept the -EXDEV error and erroneously falls through to the caseless retry logic, which is intended only for genuinely missing files. During this retry process, the path is reconstructed, leading to an unintended LOOKUP_BENEATH bypass that allows write-capable users to create zero-length files or directories outside the exported share. Fix this by ensuring that the execution only proceeds to the caseless lookup retry when the error is specifically -ENOENT. Any other errors, such as -EXDEV from a path traversal attempt, must be returned immediately. Cc: stable@vger.kernel.org Reported-by: Y s65 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3eaec47518e126e6dcd1a48521d740278073f0ec Author: Ralph Boehme Date: Sun Jun 7 15:23:18 2026 +0200 smb/client: fix chown/chgrp with SMB3 POSIX Extensions [ Upstream commit 760ef2c579c2609cf17fb1cd5392f64d42d43d33 ] Ownership (chown) and group (chgrp) modifications were being ignored when mounting with SMB3 POSIX Extensions unless CIFS_MOUNT_CIFS_ACL or CIFS_MOUNT_MODE_FROM_SID were also explicitly set. Fix this by checking for posix_extensions in cifs_setattr_nounix() when updating UID and GID, ensuring that id_mode_to_cifs_acl() is called to map and set the ownership/group information on the server. Cc: stable@vger.kernel.org Signed-off-by: Ralph Boehme Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d16713c06006669c7162dfab1cedf4cb24429311 Author: Arjan van de Ven Date: Mon May 4 07:51:06 2026 -0700 wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon [ Upstream commit 351dd7d2c80d23e56dcce6faa4e62bea5b0877c7 ] This patch is based on a BUG as reported by Bongani Hlope at https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/ When a channel-switch announcement (CSA) beacon is received, cfg80211 queues a wiphy work item that eventually calls mt7921_channel_switch_rx_beacon(). If the station disconnects (or the channel context is otherwise torn down) between the time the work is queued and the time it runs, the driver's dev->new_ctx pointer can already have been cleared to NULL. mt7921_channel_switch_rx_beacon() then dereferences new_ctx unconditionally, triggering a NULL pointer dereference at address 0x0: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:mt7921_channel_switch_rx_beacon+0x1f/0x100 [mt7921_common] The same missing guard exists in mt7925_channel_switch_rx_beacon(), which shares the same code pattern introduced by the same commit. Add an early-return NULL check for dev->new_ctx in both mt7921_channel_switch_rx_beacon() and mt7925_channel_switch_rx_beacon(). When new_ctx is NULL there is no pending channel switch to process, so returning immediately is the correct and safe action. Fixes: 8aa2f59260eb ("wifi: mt76: mt7921: introduce CSA support") Reported-by: Bongani Hlope Oops-Analysis: http://oops.fenrus.org/reports/lkml/20260502125824.425d7159@bongani-mini.home.org.za/report.html Link: https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/ Signed-off-by: Arjan van de Ven Cc: linux-wireless@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: Felix Fietkau Cc: Lorenzo Bianconi Cc: Ryder Lee Link: https://patch.msgid.link/20260504145107.1329197-1-arjan@linux.intel.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3f9c0fdefa0431ad7a5528d76b9cdad912500bdf Author: Sean Christopherson Date: Tue Jun 2 10:09:19 2026 -0700 KVM: guest_memfd: Treat memslot binding offset+size as unsigned values [ Upstream commit eba85fee7fc6cf28fec38a5bf3c378bef9a79ca6 ] When binding a memslot to a guest_memfd file, treat the offset and size as unsigned values to fix a bug where the sum of the two can result in a false negative when checking for overflow against the size of the file. Passing unsigned values also avoids relying on somewhat obscure checks in other flows for safety, and tracks the offset and size as they are intended to be tracked, as unsigned values. On 64-bit kernels, the number of pages a memslot contains and thus the size (and offset) of its guest_memfd binding are unsigned 64-bit values. Taking the offset+size as an loff_t instead of a uoff_t inadvertently converts the unsigned value to a signed value if the offset and/or size is massive. Locally storing the offset and size as signed values is benign in and of itself (though even that is *extremely* difficult to discern), but operating on their sum is not. For the offset, KVM explicitly checks against a negative value, which might seem like a bug as KVM could incorrectly reject a legitimate binding, but that's not actually the case as KVM_CREATE_GUEST_MEMFD takes a signed value for its size, i.e. a would-be-negative offset is also greater than the maximum possible size of any guest_memfd file. Regarding the size, while KVM lacks an explicit check for a negative value, i.e. seemingly has a flawed overflow check, KVM restricts the number of pages in a single memslot to the largest positive signed 32-bit value: if (id < KVM_USER_MEM_SLOTS && (mem->memory_size >> PAGE_SHIFT) > KVM_MEM_MAX_NR_PAGES) return -EINVAL; and so that maximum "size" will ever be is 0x7fffffff000. The sum of the two is, however, problematic. While the size is restricted by KVM's memslot logic, the offset is not, i.e. the offset is completely unchecked until the "offset + size > i_size_read(inode)" check. If the offset is the (nearly) largest possible _positive_ value, then adding size to the offset can result in a signed, negative 64-bit value. When compared against the size of the file (guaranteed to be positive), the negative sum is always smaller, and KVM incorrectly allows the absurd offset. Opportunistically add missing includes in kvm_mm.h (instead of relying on its parents). Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: stable@vger.kernel.org Cc: Ackerley Tng Reviewed-by: Michael Roth Reviewed-by: Ackerley Tng Link: https://patch.msgid.link/20260602170921.1304394-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 5afc2d9b86bed2e4d9e1ba467790cbc793223f98 Author: David Howells Date: Tue May 12 13:33:43 2026 +0100 netfs: Fix zeropoint update where i_size > remote_i_size [ Upstream commit 4543a4d737944134a1394afe797622546fbcc98a ] Fix the update of the zero point[*] by netfs_release_folio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. i_size > remote_i_size). The update needs to limit zero_point to remote_i_size, not i_size as i_size is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remote_i_size tracks the server's i_size. [*] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads. Note that netfs_invalidate_folio() probably doesn't need fixing as zero_point should be updated by setattr after truncation or fallocate. Found with: fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops using the following as junk.fsxops: truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copy_range 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f on cifs with the default cache option. It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODE_READ check is commented out in netfs_perform_write(): if (//(file->f_mode & FMODE_READ) || netfs_is_cache_enabled(ctx)) { and no fscache. This was initially found with the generic/522 xfstest. Fixes: cce6bfa6ca0e ("netfs: Fix trimming of streaming-write folios in netfs_inval_folio()") Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-7-dhowells@redhat.com cc: Paulo Alcantara cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit b76568c6721840a4ddb65e24e2849db0f8e83461 Author: Felix Gu Date: Sat Jan 24 00:37:38 2026 +0800 drm/msm/adreno: Fix a reference leak in a6xx_gpu_init() [ Upstream commit e64bca63647db1d5518198d6c5ca2dbcc66b182b ] In a6xx_gpu_init(), node is obtained via of_parse_phandle(). While there was a manual of_node_put() at the end of the common path, several early error returns would bypass this call, resulting in a reference leak. Fix this by using the __free(device_node) cleanup handler to release the reference when the variable goes out of scope. Fixes: 5a903a44a984 ("drm/msm/a6xx: Introduce GMU wrapper support") Signed-off-by: Felix Gu Patchwork: https://patchwork.freedesktop.org/patch/700661/ Message-ID: <20260124-a6xx_gpu-v1-1-fa0c8b2dcfb1@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit fcb23bb31508b62e8a1b32adf6217820e90e29b0 Author: Jia Zhu Date: Tue Oct 6 00:11:29 2026 -0400 erofs: fix metabuf leak in inode xattr initialization [ Upstream commit 79b09c54c6563df9846ca3094bcfd72082c3e1d7 ] commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofs_buf instances. erofs_init_inode_xattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array. Some error paths after erofs_read_metabuf() leave through out_unlock without dropping the metabuf, so the folio reference can leak. Consolidate the cleanup at out_unlock. erofs_put_metabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFS_I_BL_XATTR_BIT covered by a single cleanup site. Fixes: bb88e8da0025 ("erofs: use meta buffers for xattr operations") Signed-off-by: Jia Zhu Reviewed-by: Gao Xiang Fixes: bb88e8da0025 ("erofs: use meta buffers for xattr operations") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 48d09dea506de667eb55f939bf98eec721effbdb Author: Michael Bommarito Date: Wed May 13 19:38:38 2026 -0400 net: hsr: defer node table free until after RCU readers [ Upstream commit aaec7096f9961eb223b5b149abe9495525c205d9 ] HSR node-list and node-status generic-netlink operations run under rcu_read_lock(). They walk hsr->node_db through hsr_get_next_node() and hsr_get_node_data(), but RTM_DELLINK teardown removes the same node table with plain list_del() and frees each node immediately. That lets a generic-netlink reader hold a struct hsr_node pointer across hsr_dellink(). In a KASAN build, widening the reader window after hsr_get_next_node() obtains the node reproduces a slab-use-after-free when the reader copies node->macaddress_A; the freeing stack is hsr_del_nodes() from hsr_dellink(). Use list_del_rcu() and defer the free through the existing hsr_free_node_rcu() callback. This matches the lifetime rule used by the HSR prune paths, which already delete nodes with list_del_rcu() and call_rcu(). Fixes: b9a1e627405d ("hsr: implement dellink to clean up resources") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260513233838.3064715-2-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2650f8461cd8ba287fee2992b36abe733c2bd5e Author: Zhao Li Date: Sat May 9 12:34:28 2026 +0800 wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb [ Upstream commit d71c841be5d9e586ee7f36c0dc8ed4db0d9a1349 ] ieee80211_invoke_fast_rx() reads RX status through IEEE80211_SKB_RXCB(skb), which aliases the same skb->cb storage that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO. In the unicast forward path, mesh_data does: info = IEEE80211_SKB_CB(fwd_skb); memset(info, 0, sizeof(*info)); on the same skb the caller still names via rx->skb, then either queues the skb for TX (success) or kfree_skb()'s it (no-route) before returning RX_QUEUED. The caller's RX_QUEUED arm then calls sta_stats_encode_rate(status) on memory that is either zeroed (success path) or freed (no-route path). The latter is KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle. Fix by encoding the rate from status before invoking ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value captured while status was still backed by valid memory. Fixes: 3468e1e0c639 ("wifi: mac80211: add mesh fast-rx support") Cc: stable@vger.kernel.org Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260509043427.60322-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3899d6f924925640641aa6574d754a5cfbd12617 Author: Sarika Sharma Date: Fri Oct 24 10:06:27 2025 +0530 wifi: mac80211: fix missing RX bitrate update for mesh forwarding path [ Upstream commit cc18fffa3a51792637169872886df3407bd5bb84 ] Currently, RX bitrate statistics are not updated for packets received on the mesh forwarding path during fast RX processing. This results in incomplete RX rate tracking in station dump outputs for mesh scenarios. Update ieee80211_invoke_fast_rx() to record the RX rate using sta_stats_encode_rate() and store it in the last_rate field of ieee80211_sta_rx_stats when RX_QUEUED is returned from ieee80211_rx_mesh_data(). This ensures that RX bitrate is properly accounted for in both RSS and non-RSS paths. Signed-off-by: Sarika Sharma Link: https://patch.msgid.link/20251024043627.1640447-1-sarika.sharma@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: d71c841be5d9 ("wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb") Signed-off-by: Sasha Levin commit f669571a2bf5067f50091cc598df9613663ee226 Author: Florian Westphal Date: Wed May 6 12:07:14 2026 +0200 netfilter: x_tables: allocate hook ops while under mutex [ Upstream commit b62eb8dcf2c47d4d676a434efbd57c4f776f7829 ] arp/ip(6)t_register_table() add the table to the per-netns list via xt_register_table() before allocating the per-netns hook ops copy via kmemdup_array(). This leaves a window where the table is visible in the list with ops=NULL. If the pernet exit happens runs concurrently the pre_exit callback finds the table via xt_find_table() and passes the NULL ops pointer to nf_unregister_net_hooks(), causing a NULL dereference: general protection fault in nf_unregister_net_hooks+0xbc/0x150 RIP: nf_unregister_net_hooks (net/netfilter/core.c:613) Call Trace: ipt_unregister_table_pre_exit iptable_mangle_net_pre_exit ops_pre_exit_list cleanup_net Fix by moving the ops allocation into the xtables core so the table is never in the list without valid ops. Also ensure the table is no longer processing packets before its torn down on error unwind. nf_register_net_hooks might have published at least one hook; call synchronize_rcu() if there was an error. audit log register message gets deferred until all operations have passed, this avoids need to emit another ureg message in case of error unwinding. Based on earlier patch by Tristan Madani. Fixes: f9006acc8dfe5 ("netfilter: arp_tables: pass table pointer via nf_hook_ops") Fixes: ee177a54413a ("netfilter: ip6_tables: pass table pointer via nf_hook_ops") Fixes: ae689334225f ("netfilter: ip_tables: pass table pointer via nf_hook_ops") Link: https://lore.kernel.org/netfilter-devel/20260429175613.1459342-1-tristmd@gmail.com/ Signed-off-by: Tristan Madani Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a014668cbd95b0d7bffe09efc556dfa04c3b357c Author: Florian Westphal Date: Wed May 6 12:07:13 2026 +0200 netfilter: x_tables: allow initial table replace without emitting audit log message [ Upstream commit 8e72510db9fa2d41f2b06d5c01fe9020e076fee4 ] At the moment we emit the audit log a bit too early, which makes it necessary to also emit an unregister log in case we have to unwind errors after possible hook register failure. Followup patch will be slightly simpler if we can delay the register message until after the hooks have been wired up. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: b62eb8dcf2c4 ("netfilter: x_tables: allocate hook ops while under mutex") Signed-off-by: Sasha Levin commit f048f297d93fdb19d72d01d22f04c419d8b16602 Author: David Howells Date: Tue May 12 13:33:40 2026 +0100 netfs: Fix missing barriers when accessing stream->subrequests locklessly [ Upstream commit b5782e2d462c028096f922abca46318cec890670 ] The list of subrequests attached to stream->subrequests is accessed without locks by netfs_collect_read_results() and netfs_collect_write_results(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if no lock is taken. Fix this by: (1) Add a new list_add_tail_release() function that uses a release barrier to set the pointer to the new member of the list. (2) Add a new list_first_entry_or_null_acquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL). (3) Use list_add_tail_release() when adding a subreq to ->subrequests. (4) Use list_first_entry_or_null_acquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock). Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Link: https://sashiko.dev/#/patchset/20260326104544.509518-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-4-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 93531bca46707c6c28c4f4eb26c101fa36ccb8cb Author: David Howells Date: Tue May 12 13:34:01 2026 +0100 afs: Fix the locking used by afs_get_link() [ Upstream commit c0410adf3da6db46f3513411fcf95e63c2f1d1ad ] The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems: (1) It doesn't do any locking around afs_read_single() to prevent races between multiple ->get_link() calls, thereby allowing the possibility of leaks. (2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk. (3) It can race with another thread updating the contents of the symlink if a third party updated it on the server. Fix this by the following means: (0) Move symlink handling into its own file as this makes it more complicated. (1) Take the validate_lock around afs_read_single() to prevent races between multiple ->get_link() calls. (2) Keep a separate copy of the symlink contents with an rcu_head. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk. (3) Split the symlink read and write-to-cache routines in afs from those for directories. (4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folio_queue). (5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache. Fixes: eae9e78951bb ("afs: Use netfslib for symlinks, allowing them to be cached") Fixes: 6698c02d64b2 ("afs: Locally initialise the contents of a new symlink on creation") Closes: https://sashiko.dev/#/patchset/20260326104544.509518-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-25-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 86f4c1586418d50203ee8d76cba5d7b148719a32 Author: Hongling Zeng Date: Wed May 13 18:34:06 2026 +0800 cachefiles: Fix error return when vfs_mkdir() fails [ Upstream commit 8a220d1c312c66194f4a33dd52d1fba42bc2b341 ] When vfs_mkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdir_error to be reached with ret=0, which leads to returning ERR_PTR(0) (NULL) instead of a proper error pointer. Fix this by extracting the error code from the error pointer when vfs_mkdir() fails. Fixes: 406fad7698f5 ("cachefiles: Fix oops in vfs_mkdir from cachefiles_get_directory") Signed-off-by: Hongling Zeng Link: https://patch.msgid.link/20260513103406.202320-1-zenghongling@kylinos.cn Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit b9390aa62fdcabdaac2d09545be05901f6cecaf5 Author: Keith Busch Date: Tue May 19 18:03:44 2026 -0700 nvme-pci: fix dma_vecs leak on p2p memory [ Upstream commit 85686c72966c5ee637893f124ddb31a1cace7bee ] We don't unmap P2P memory, so we don't need to track it. The dma_vec allocation was getting leaked on the completion. Fixes: b8b7570a7ec87 ("nvme-pci: fix dma unmapping when using PRPs and not using the IOVA mapping") Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit fba32257979dda14b0d8ed7402490ae0be44972a Author: Keith Busch Date: Tue May 19 13:01:57 2026 -0700 nvme-pci: fix dma mapping leak on data setup error [ Upstream commit 1bf86336e4b6cf40873fda47a7fe191446864937 ] We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided. The mappings were also leaking when the driver detects an invalid bio_vec when mapping PRPs, so fix that too. Fixes: b8b7570a7ec87 ("nvme-pci: fix dma unmapping when using PRPs and not using the IOVA mapping") Fixes: 7ce3c1dd78fca ("nvme-pci: convert the data mapping to blk_rq_dma_map") Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c85f325d9ec3116b0d4ee9d5b76c26aea0ad5ce0 Author: Rafael J. Wysocki Date: Fri May 22 16:49:44 2026 +0200 ACPI: button: Fix ACPI GPE handler leak during removal [ Upstream commit fe80251152fed5b185f795ef2cd9f7fe9c3162e0 ] Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail. Address this by updating the acpi_remove_notify_handler() call in acpi_button_remove() as appropriate. Fixes: a7e23ec17fee ("ACPI: button: Install notifier for system events as well") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Cc: 6.15+ # 6.15+ Link: https://patch.msgid.link/7954431.EvYhyI6sBW@rafael.j.wysocki Signed-off-by: Sasha Levin commit 78677084cd09001c3c815aab80c59708130a65d7 Author: Rafael J. Wysocki Date: Thu Feb 12 14:33:00 2026 +0100 ACPI: button: Tweak acpi_button_remove() [ Upstream commit 1abdf9e7967f154b3d4bfe0681dd38b8e036ee63 ] Modify acpi_button_remove() to get the ACPI device object pointer from button->adev instead of retrieving it with the help of the ACPI_COMPANION() macro to reduce overhead slightly. While at it, rename the struct acpi_device pointer variable in acpi_button_remove() to adev. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/13948466.uLZWGnKmhe@rafael.j.wysocki Stable-dep-of: fe80251152fe ("ACPI: button: Fix ACPI GPE handler leak during removal") Signed-off-by: Sasha Levin commit 38c79dacc8063ff8a0d75ce2a900fbaff82ad94c Author: Rafael J. Wysocki Date: Mon Dec 15 14:57:57 2025 +0100 ACPI: button: Convert the driver to a platform one [ Upstream commit 52d86401963666423cb9a56d117136c846093db0 ] While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI button driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2461734.NG923GbCHz@rafael.j.wysocki Stable-dep-of: fe80251152fe ("ACPI: button: Fix ACPI GPE handler leak during removal") Signed-off-by: Sasha Levin commit bad88022f8949f9d2379b8a16f47432bbe9cc74b Author: Rafael J. Wysocki Date: Mon Dec 15 14:55:09 2025 +0100 ACPI: button: Adjust event notification routines [ Upstream commit 93dc5db6d47aaa3b4b458ddfddfa3369c24e22f4 ] Adjust the event notification routines in the ACPI button driver to take a struct acpi_button pointer as an argument istead of a struct acpi_device one where applicable, which allows the use of acpi_driver_data() to be limited and will facilitate subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2260995.Icojqenx9y@rafael.j.wysocki Stable-dep-of: fe80251152fe ("ACPI: button: Fix ACPI GPE handler leak during removal") Signed-off-by: Sasha Levin commit 4ec3a8ca97394f17e73a4d8d4c79c1c78b322772 Author: Jamal Hadi Salim Date: Mon May 25 08:25:51 2026 -0400 net/sched: fix packet loop on netem when duplicate is on [ Upstream commit 9552b11e3edabc97cfcd9f29103d5afbce7ae183 ] When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted. The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking. Use the skb tc_depth field introduced in an earlier patch: - increment it on the duplicate before re-enqueue - skip duplication for any skb whose tc_depth is already non-zero. This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency. Fixes: 0afb51e72855 ("[PKT_SCHED]: netem: reinsert for duplication") Reported-by: William Liu Reported-by: Savino Dicanosa Closes: https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ Co-developed-by: Victor Nogueira Signed-off-by: Victor Nogueira Reviewed-by: William Liu Reviewed-by: Stephen Hemminger Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260525122556.973584-5-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b050fd0c2063bb48f4d313910a081edbbb991329 Author: Jamal Hadi Salim Date: Mon May 25 08:25:48 2026 -0400 net: Introduce skb tc depth field to track packet loops [ Upstream commit 98b34f3e8c3492cfc89ff943c9d92b4d52863d1d ] Add a 2-bit per-skb tc depth field to track packet loops across the stack. The previous per-CPU loop counters like MIRRED_NEST_LIMIT assume a single call stack and lose state in two cases: 1) When a packet is queued and reprocessed later (e.g., egress->ingress via backlog), the per-cpu state is gone by the time it is dequeued. 2) With XPS/RPS a packet may arrive on one CPU and be processed on another. A per-skb field solves both by travelling with the packet itself. The field fits in existing padding, using 2 bits that were previously a hole: pahole before(-) and after (+) diff looks like: __u8 slow_gro:1; /* 132: 3 1 */ __u8 csum_not_inet:1; /* 132: 4 1 */ __u8 unreadable:1; /* 132: 5 1 */ + __u8 tc_depth:2; /* 132: 6 1 */ - /* XXX 2 bits hole, try to pack */ /* XXX 1 byte hole, try to pack */ __u16 tc_index; /* 134 2 */ There used to be a ttl field which was removed as part of tc_verd in commit aec745e2c520 ("net-tc: remove unused tc_verd fields"). It was already unused by that time, due to remove earlier in commit c19ae86a510c ("tc: remove unused redirect ttl"). The first user of this field is netem, which increments tc_depth on duplicated packets before re-enqueueing them at the root qdisc. On re-entry, netem skips duplication for any skb with tc_depth already set, bounding recursion to a single level regardless of tree topology. The other user is mirred which increments it on each pass and limits to depth to MIRRED_DEFER_LIMIT (3). The new field was called ttl in earlier versions of this patch but renamed to tc_depth to avoid confusion with IP ttl. Note (looking at you Sashiko! Dont ignore me and continue bringing this up): 1. Since both mirred and netem utilize the same 2-bit tc_depth field it is possible when netem and mirred are used together that netem qdisc to skip the duplication step. This is a known trade-off, as a 2-bit field cannot independently track both features' recursion depths and it is not considered sane to have a setup that addresses both features on at the same time. 2. skb_scrub_packet does not clear tc_depth. This means a packet's loop history is preserved even across namespaces. While this might be restrictive for some topologies, it is also design intent to provide robustness against loops across namespaces. Reviewed-by: Stephen Hemminger Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260525122556.973584-2-jhs@mojatatu.com Signed-off-by: Paolo Abeni Stable-dep-of: 9552b11e3eda ("net/sched: fix packet loop on netem when duplicate is on") Signed-off-by: Sasha Levin commit 2090c1a2368339eab0e14dcde12fdf6a5ea6359d Author: Mark Brown Date: Fri May 29 00:01:44 2026 +0100 KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor [ Upstream commit 83726330748981372bde86ed5411d7b306612991 ] ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2 (which traps) or ZCR_EL1 (which does not trap). KVM handles both in different way: - on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM's own VL limit. This has the potential to break existing SW that relies on the full LEN field to be stateful. - on ZCR_EL1 access, we do absolutely nothing. On restoring the SVE context for an L2 guest, we directly restore the guest hypervisor's view of ZCR_EL2 into the physical ZCR_EL2. If the guest's view of the register was updated using the ZCR_EL2 accessor, the value has already been sanitised (with the caveat mentioned above). But if the guest used ZCR_EL1, the raw value is written into the HW, and the L2 guest can now access VLs that it shouldn't. Fix all the above by moving the VL capping to the restore points, ensuring that: - the HW is always programmed with a capped value, irrespective of the accessor being used, - the ZCR_EL2.LEN field is always completely stateful, irrespective of the accessor being used. Additionally, move ZCR_EL2 to be a sanitised register, ensuring that only the LEN field is actually stateful. This requires some creative construction of the RES0 mask, as the sysreg generation script does not yet generate RAZ/WI fields. Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260529-kvm-arm64-fix-zcr-len-nv-v2-1-86cad51992bd@kernel.org [maz: rewrote commit message, tidy up access_zcr_el2()] Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit fa34d3e14cb763b50702e8a0f7d4cfd877a73ab9 Author: Christian König Date: Wed Feb 18 12:53:27 2026 +0100 drm/amdgpu: fix amdgpu_hmm_range_get_pages [ Upstream commit 962d684b5dc0741dcd93485d41b450de402d5592 ] The notifier sequence must only be read once or otherwise we could work with invalid pages. While at it also fix the coding style, e.g. drop the pre-initialized return value and use the common define for 2G range. Signed-off-by: Christian König Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit c08972f555945cda57b0adb72272a37910153390) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 768daa9f4276be4007e88dea61a378c8582ba008 Author: Pablo Neira Ayuso Date: Wed Apr 15 22:58:23 2026 +0200 netfilter: nf_tables: add hook transactions for device deletions [ Upstream commit 10f79dbd7719d1da9f5884d13060322d8729f091 ] Restore the flag that indicates that the hook is going away, ie. NFT_HOOK_REMOVE, but add a new transaction object to track deletion of hooks without altering the basechain/flowtable hook_list during the preparation phase. The existing approach that moves the hook from the basechain/flowtable hook_list to transaction hook_list breaks netlink dump path readers of this RCU-protected list. It should be possible use an array for nft_trans_hook to store the deleted hooks to compact the representation but I am not expecting many hook object, specially now that wildcard support for devices is in place. Note that the nft_trans_chain_hooks() list contains a list of struct nft_trans_hook objects for DELCHAIN and DELFLOWTABLE commands, while this list stores struct nft_hook objects for NEWCHAIN and NEWFLOWTABLE. Note that new commands can be updated to use nft_trans_hook for consistency. This patch also adapts the event notification path to deal with the list of hook transactions. Fixes: 7d937b107108 ("netfilter: nf_tables: support for deleting devices in an existing netdev chain") Fixes: b6d9014a3335 ("netfilter: nf_tables: delete flowtable hooks via transaction list") Reported-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7e4ab3907f44dc243d026048d7f5d477dae9267b Author: Mikhail Lobanov Date: Mon Jun 15 14:36:13 2026 +0300 f2fs: read COW data with the original inode during atomic write [ Upstream commit a41075acde0124d2f8a5f563068a5d63e8ffd57b ] When updating an atomic-write file, f2fs_write_begin() may read the previously written data back from the COW inode: prepare_atomic_write_begin() locates the block in the COW inode and sets use_cow, and the read bio is then built with the COW inode: f2fs_submit_page_read(use_cow ? F2FS_I(inode)->cow_inode : inode, ...); and f2fs_grab_read_bio() decides whether to schedule fs-layer decryption (STEP_DECRYPT) for the bio based on that inode via fscrypt_inode_uses_fs_layer_crypto(). However, the folio being filled belongs to the original inode (folio->mapping->host == inode), and the data stored in the COW block was encrypted (or left as plaintext) using the original inode's context, not the COW inode's -- see f2fs_encrypt_one_page(), which keys off fio->page->mapping->host. fscrypt_decrypt_pagecache_blocks() likewise operates on folio->mapping->host. The COW inode is created as a tmpfile in the parent directory and inherits its encryption policy from there. With test_dummy_encryption the newly created COW inode gets the dummy policy and becomes encrypted, while a pre-existing regular file -- created before the policy applied, e.g. already present in the on-disk image -- stays unencrypted. The read path then sets STEP_DECRYPT based on the encrypted COW inode and calls fscrypt_decrypt_pagecache_blocks() on a folio whose host (the unencrypted original inode) has a NULL ->i_crypt_info, dereferencing it: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:fscrypt_decrypt_pagecache_blocks+0xa0/0x310 Workqueue: f2fs_post_read_wq f2fs_post_read_work Call Trace: fscrypt_decrypt_bio+0x1eb/0x340 f2fs_post_read_work+0xba/0x140 process_one_work+0x91c/0x1a40 worker_thread+0x677/0xe90 kthread+0x2bc/0x3a0 The COW inode is only needed to locate the on-disk block, and that block address is already resolved into @blkaddr by prepare_atomic_write_begin() via __find_data_block(cow_inode, ...); f2fs_submit_page_read() then reads from that physical @blkaddr directly, so the inode argument only selects the post-read crypto context, not which block is fetched. Reading with @inode therefore returns the same (latest, not-yet-committed) COW data, while making both the fs-layer decryption decision and the inline crypto path use the correct (original inode's) key. With the COW inode no longer used at the read site, the use_cow flag has no remaining consumer; drop it from f2fs_write_begin() and prepare_atomic_write_begin(). Fixes: 591fc34e1f98 ("f2fs: use cow inode data when updating atomic write") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Lobanov Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 8363c219d88e78daaee5665117a0380442989338 Author: Hongling Zeng Date: Tue Jun 2 16:54:21 2026 +0800 fbdev: omap2: fix use-after-free in omapfb_mmap [ Upstream commit 7958e67375aa111522086286bba13cfc0816ce8d ] omapfb_mmap() has a race condition with OMAPFB_SETUP_PLANE ioctl that can lead to use-after-free: The fb_mmap() entry point holds mm_lock but not lock (fb_info->lock), while ioctl handlers like OMAPFB_SETUP_PLANE hold lock but not mm_lock. This allows concurrent execution. In omapfb_mmap(): 1. rg = omapfb_get_mem_region(ofbi->region); // Get old region ref 2. start = omapfb_get_region_paddr(ofbi); // Read from NEW region 3. len = fix->smem_len; // Read from NEW region 4. vm_iomap_memory(vma, start, len); // Map NEW region memory 5. atomic_inc(&rg->map_count); // Increment OLD region! Concurrently, OMAPFB_SETUP_PLANE can: - Reassign ofbi->region = new_rg - Update fix->smem_len - OMAPFB_SETUP_MEM then checks NEW region's map_count (0!) and frees it This leaves userspace with a mapping to freed physical memory. The fix is to read all required values (start, len) from the same region reference (rg) that will have its map_count incremented, preventing the region from being freed while still mapped. Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 48ac6bab9999baecde4f5394bffc1024f8591932 Author: Hongling Zeng Date: Thu Apr 2 17:34:03 2026 +0800 fbdev: omap2: fix inconsistent lock returns in omapfb_mmap [ Upstream commit 98cf7df6e0844f7076df1db690c1ede9d69b61ff ] Fix the warning about inconsistent returns for '&rg->lock' in omapfb_mmap() function. The warning arises because the error path uses 'ofbi->region' while the normal path uses 'rg'. smatch warnings: drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1126 omapfb_mmap() warn: inconsistent returns '&rg->lock'. Reported-by: kernel test robot Signed-off-by: Hongling Zeng Signed-off-by: Helge Deller Stable-dep-of: 7958e67375aa ("fbdev: omap2: fix use-after-free in omapfb_mmap") Signed-off-by: Sasha Levin commit 4338663dfd21b9c6b012185e5c898769acb60692 Author: Krzysztof Kozlowski Date: Thu Mar 5 22:45:43 2026 +0100 power: supply: max77705: Free allocated workqueue and fix removal order [ Upstream commit 1e668baadefb16e81269dbfebf3ffc2672e3a3bb ] Use devm interface for allocating workqueue to fix two bugs at the same time: 1. Driver leaks the memory on remove(), because the workqueue is not destroyed. 2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt. The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory. Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update power supply (power_supply_changed()) status, thus there is no point to run it for memory reclaim. Note that dev_name() is not directly used in second argument to prevent possible unlikely parsing any "%" character in device name as format. Fixes: 11741b8e382d ("power: supply: max77705: Fix workqueue error handling in probe") Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260305-workqueue-devm-v2-4-66a38741c652@oss.qualcomm.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 4e1af66d855f5a8aa8cb92c55f7c3c72e7e4d490 Author: Krzysztof Kozlowski Date: Thu Mar 5 22:45:42 2026 +0100 power: supply: max77705: Drop duplicated IRQ error message [ Upstream commit 2064c64ceb1996ee02a6bbb1de05fd6e8028e3e4 ] Core already prints error message on devm_request_threaded_irq() failure, so no need to do that second time. Suggested-by: Andy Shevchenko Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260305-workqueue-devm-v2-3-66a38741c652@oss.qualcomm.com Signed-off-by: Sebastian Reichel Stable-dep-of: 1e668baadefb ("power: supply: max77705: Free allocated workqueue and fix removal order") Signed-off-by: Sasha Levin commit fa4be2054a3e2a9938bfac8a655819816025059f Author: Krzysztof Kozlowski Date: Thu Mar 5 22:45:40 2026 +0100 workqueue: devres: Add device-managed allocate workqueue [ Upstream commit 1dfc9d60a69ec148e1cb709256617d86e5f0e8f8 ] Add a Resource-managed version of alloc_workqueue() to fix common problem of drivers mixing devm() calls with destroy_workqueue. Such naive and discouraged driver approach leads to difficult to debug bugs when the driver: 1. Allocates workqueue in standard way and destroys it in driver remove() callback, 2. Sets work struct with devm_work_autocancel(), 3. Registers interrupt handler with devm_request_threaded_irq(). Which leads to following unbind/removal path: 1. destroy_workqueue() via driver remove(), Any interrupt coming now would still execute the interrupt handler, which queues work on destroyed workqueue. 2. devm_irq_release(), 3. devm_work_drop() -> cancel_work_sync() on destroyed workqueue. devm_alloc_workqueue() has two benefits: 1. Solves above problem of mix-and-match devres and non-devres code in driver, 2. Simplify any sane drivers which were correctly using alloc_workqueue() + devm_add_action_or_reset(). Signed-off-by: Krzysztof Kozlowski Acked-by: Tejun Heo Reviewed-by: Andy Shevchenko Signed-off-by: Tejun Heo Stable-dep-of: 1e668baadefb ("power: supply: max77705: Free allocated workqueue and fix removal order") Signed-off-by: Sasha Levin commit 5459933a799aaf642cbeb35fdf7e78c59bf2fb9b Author: Morduan Zang Date: Thu Apr 23 09:05:57 2026 +0800 net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind [ Upstream commit 5b0c911bcdbd982f7748d11c0b39ec5808eae2de ] syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via pn_socket_autobind(): kernel BUG at net/phonet/socket.c:213! RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline] RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: sock_sendmsg_nosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] __sys_sendto+0x402/0x590 net/socket.c:2280 ... pn_socket_autobind() calls pn_socket_bind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero: err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn)); if (err != -EINVAL) return err; BUG_ON(!pn_port(pn_sk(sock->sk)->sobject)); return 0; /* socket was already bound */ However pn_socket_bind() also returns -EINVAL when sk->sk_state is not TCP_CLOSE, even when the socket has never been bound and pn_port() is still 0. In that case the BUG_ON() fires and panics the kernel from a user-triggerable path. Treat the "bind returned -EINVAL but pn_port() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno. Fixes: ba113a94b750 ("Phonet: common socket glue") Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794 Suggested-by: Remi Denis-Courmont Signed-off-by: Morduan Zang Signed-off-by: zhanjun Acked-by: Rémi Denis-Courmont Link: https://patch.msgid.link/87A8960A2045AF3C+20260423010557.138124-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8c1480bb066cf0f6e79129b7292e1c99ff68b9b Author: Mikhail Gavrilov Date: Tue May 5 09:05:37 2026 +0800 drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED [ Upstream commit 183182235f6d53bac62c6c39014738a54a68dfa6 ] [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. Fixes: 235c67634230 ("drm/amd/display: add DCN32/321 specific files for Display Core") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4470 Reviewed-by: Aurabindo Pillai Signed-off-by: Mikhail Gavrilov Signed-off-by: James Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit afe815a67ec8f2fd03c261fb64f5cde7eb05c17a Author: Johannes Berg Date: Wed Jun 3 11:18:11 2026 +0200 wifi: cfg80211: enforce HE/EHT cap/oper consistency [ Upstream commit cb9959ab5f99611d27a06586add84811fe8102dc ] Xiang Mei reports that mac80211 could crash if eht_cap is set but eht_oper isn't. Rather than fixing that for the individual user(s), enforce that both HE/EHT have consistent elements. Reported-by: Xiang Mei Fixes: 22c64f37e1d4 ("wifi: mac80211: Update MCS15 support in link_conf") Link: https://patch.msgid.link/20260603091812.101894-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit daacc9d1430b63f6bee6e5646def5d6414d35c4e Author: Vadim Fedorenko Date: Mon Jun 8 15:59:52 2026 +0000 ptp: ocp: fix resource freeing order [ Upstream commit 627366c51145a07f675b1800fb5ea2ec960bd900 ] Commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronize_irq() after HW is configured to stop producing irqs and no irqs are in-flight. Fixes: a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") Signed-off-by: Vadim Fedorenko Link: https://patch.msgid.link/20260608155952.240304-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9446167bef89bceb80a23adb19f93f9cd92994a5 Author: Andy Shevchenko Date: Mon Nov 24 09:45:46 2025 +0100 ptp: ocp: Make ptp_ocp_unregister_ext() NULL-aware [ Upstream commit 590f5d1fa6ee22b1ec07283d5fa870326f47b2f6 ] It's a common practice to make resource release functions be NULL-aware. Make ptp_ocp_unregister_ext() NULL-aware. Reviewed-by: Vadim Fedorenko Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20251124084816.205035-3-andriy.shevchenko@linux.intel.com Signed-off-by: Jakub Kicinski Stable-dep-of: 627366c51145 ("ptp: ocp: fix resource freeing order") Signed-off-by: Sasha Levin commit de05e37d02f3f33ebca4967164e54f5fea809d86 Author: Uday Shankar Date: Sun Apr 5 22:25:30 2026 -0600 ublk: reset per-IO canceled flag on each fetch [ Upstream commit 0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b ] If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen). Signed-off-by: Uday Shankar Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()") Reviewed-by: Ming Lei Reviewed-by: zhang, the-essence-of-life Link: https://patch.msgid.link/20260405-cancel-v2-1-02d711e643c2@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 09207dc57ab4cb8967e6cad55a37e15ff8523d41 Author: Ritesh Harjani (IBM) Date: Mon Mar 9 23:44:25 2026 +0530 powerpc/64s: Fix unmap race with PMD migration entries [ Upstream commit bbcbf045d6c778e82b47a35fc8728387708e9a3d ] The following race is possible with migration swap entries or device-private THP entries. e.g. when move_pages is called on a PMD THP page, then there maybe an intermediate state, where PMD entry acts as a migration swap entry (pmd_present() is true). Then if an munmap happens at the same time, then this VM_BUG_ON() can happen in pmdp_huge_get_and_clear_full(). This patch fixes that. Thread A: move_pages() syscall add_folio_for_migration() mmap_read_lock(mm) folio_isolate_lru(folio) mmap_read_unlock(mm) do_move_pages_to_node() migrate_pages() try_to_migrate_one() spin_lock(ptl) set_pmd_migration_entry() pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn set_pmd_at() # PMD: migration swap entry (pmd_present=0) spin_unlock(ptl) [page copy phase] # <--- RACE WINDOW --> Thread B: munmap() mmap_write_downgrade(mm) unmap_vmas() -> zap_pmd_range() zap_huge_pmd() __pmd_trans_huge_lock() pmd_is_huge(): # !pmd_present && !pmd_none -> TRUE (swap entry) pmd_lock() -> # spin_lock(ptl), waits for Thread A to release ptl pmdp_huge_get_and_clear_full() VM_BUG_ON(!pmd_present(*pmdp)) # HITS! [ 287.738700][ T1867] ------------[ cut here ]------------ [ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187! cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0] pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c lr: c000000000645dec: zap_huge_pmd+0xb0/0x868 sp: c00000044037f790 msr: 800000000282b033 current = 0xc0000004032c1a00 paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09 pid = 1867, comm = a.out kernel BUG at :187! Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026 enter ? for help [link register ] c000000000645dec zap_huge_pmd+0xb0/0x868 [c00000044037f790] c00000044037f7d0 (unreliable) [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8 [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c SP (7fff9b1ee9c0) is in userspace 0:mon> zh commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"), enabled migration for device-private PMD entries. Hence this is one other path where this warning could get trigger from. ------------[ cut here ]------------ WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905 Modules linked in: test_hmm CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 Call Trace: [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable) [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c000000604707760] [c00000000063e5a4] migrate_vma_collect_pmd+0x12e8/0x16c4 [c000000604707890] [c00000000059282c] walk_pgd_range+0x7fc/0xd2c [c000000604707990] [c000000000592e40] __walk_page_range+0xe4/0x2ac [c000000604707a10] [c000000000593534] walk_page_range_mm_unsafe+0x204/0x2a4 [c000000604707ab0] [c00000000063af10] migrate_vma_setup+0x1dc/0x2e8 [c000000604707b10] [c008000006a21838] dmirror_migrate_to_system.constprop.0+0x210/0x4b0 [test_hmm] [c000000604707c30] [c008000006a245b0] dmirror_fops_unlocked_ioctl+0x454/0xa5c [test_hmm] [c000000604707d20] [c0000000006aab84] sys_ioctl+0x4ec/0x1178 [c000000604707e10] [c0000000000326a8] system_call_exception+0x128/0x350 [c000000604707e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fffbe44f50c Fixes: 75358ea359e7c ("powerpc/mm/book3s64: Fix MADV_DONTNEED and parallel page fault race") Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Reported-by: Pavithra Prakash Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/9437e5ef28d1e2f5cbdd7f8286350ce93c1d43c5.1773078178.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit e72ffe59e48a74a8d9220f5ca1d03f2194d882f0 Author: Damien Riégel Date: Tue Mar 24 10:00:38 2026 -0400 greybus: raw: fix use-after-free on cdev close [ Upstream commit 983cc2c7efbce04ecbf6328448d895044dd6ab31 ] This addresses a use-after-free bug when a raw bundle is disconnected but its chardev is still opened by an application. When the application releases the cdev, it causes the following panic when init on free is enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y): refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130 ... Call Trace: cdev_put+0x18/0x30 __fput+0x255/0x2a0 __x64_sys_close+0x3d/0x80 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7f The cdev is contained in the "gb_raw" structure, which is freed in the disconnect operation. When the cdev is released at a later time, cdev_put gets an address that points to freed memory. To fix this use-after-free, convert the struct device from a pointer to being embedded, that makes the lifetime of the cdev and of this device the same. Then, use cdev_device_add, which guarantees that the device won't be released until all references to the cdev have been released. Finally, delegate the freeing of the structure to the device release function, instead of freeing immediately in the disconnect callback. Fixes: e806c7fb8e9b ("greybus: raw: add raw greybus kernel driver") Reviewed-by: Johan Hovold Signed-off-by: Damien Riégel Link: https://patch.msgid.link/20260324140039.40001-1-damien.riegel@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cb06a07d835ba1ea250785a796243bb483e65816 Author: Yongpeng Yang Date: Tue Mar 10 17:36:14 2026 +0800 f2fs: fix data loss caused by incorrect use of nat_entry flag [ Upstream commit 238e14eb7226f883b72caccd2d37bf5707df066b ] Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows: create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return false SPO and lost 'file A' f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC flags for the nat_entry, but this does not mean that the checkpoint has actually completed successfully. However, f2fs_need_inode_block_update() checks these flags and incorrectly assumes that the checkpoint has finished. The root cause is that the semantics of IS_CHECKPOINTED and HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully completes. This patch modifies f2fs_need_inode_block_update() to acquire the sbi->node_write lock before reading the nat_entry flags, ensuring that once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the checkpoint operation has already completed. Fixes: e05df3b115e7 ("f2fs: add node operations") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 910e498613d5bf4cbe5f298c2613666c38679fab Author: Michal Schmidt Date: Thu Apr 16 17:53:28 2026 -0700 ice: fix double-free of tx_buf skb [ Upstream commit 1a303baa715e6b78d6a406aaf335f87ff35acfcd ] If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any. Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads") Assisted-by: Claude:claude-4.6-opus-high Cursor Signed-off-by: Michal Schmidt Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-4-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c789649d4334a3767210071311d58bc8e74bdec1 Author: Kohei Enju Date: Thu Apr 16 17:53:32 2026 -0700 ice: fix potential NULL pointer deref in error path of ice_set_ringparam() [ Upstream commit fa28351f970fa5138c7c5dedfe5dea480a0ee065 ] ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without clearing ICE_TX_RING_FLAGS_TXTIME bit. When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent ice_setup_tx_ring() call fails, a NULL pointer dereference could happen in the unwinding sequence: ice_clean_tx_ring() -> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set) -> ice_free_tx_tstamp_ring() -> ice_free_tstamp_ring() -> tstamp_ring->desc (NULL deref) Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue. Note that this potential issue is found by manual code review. Compile test only since unfortunately I don't have E830 devices. Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Kohei Enju Reviewed-by: Paul Greenwalt Tested-by: Rinitha S Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-8-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e98cea6d5562f546482fab8ad571e95e3fff1800 Author: Keita Morisaki Date: Thu Apr 16 17:53:31 2026 -0700 ice: fix race condition in TX timestamp ring cleanup [ Upstream commit 7c72ec18c2a4111204c2e915f8e4f6d849ce9398 ] Fix a race condition between ice_free_tx_tstamp_ring() and ice_tx_map() that can cause a NULL pointer dereference. ice_free_tx_tstamp_ring currently clears the ICE_TX_FLAGS_TXTIME flag after NULLing the tstamp_ring. This could allow a concurrent ice_tx_map call on another CPU to dereference the tstamp_ring, which could lead to a NULL pointer dereference. CPU A:ice_free_tx_tstamp_ring() | CPU B:ice_tx_map() --------------------------------|--------------------------------- tx_ring->tstamp_ring = NULL | | ice_is_txtime_cfg() -> true | tstamp_ring = tx_ring->tstamp_ring | tstamp_ring->count // NULL deref! flags &= ~ICE_TX_FLAGS_TXTIME | Fix by: 1. Reordering ice_free_tx_tstamp_ring() to clear the flag before NULLing the pointer, with smp_wmb() to ensure proper ordering. 2. Adding smp_rmb() in ice_tx_map() after the flag check to order the flag read before the pointer read, using READ_ONCE() for the pointer, and adding a NULL check as a safety net. 3. Converting tx_ring->flags from u8 to DECLARE_BITMAP() and using atomic bitops (set_bit(), clear_bit(), test_bit()) for all flag operations throughout the driver: - ICE_TX_RING_FLAGS_XDP - ICE_TX_RING_FLAGS_VLAN_L2TAG1 - ICE_TX_RING_FLAGS_VLAN_L2TAG2 - ICE_TX_RING_FLAGS_TXTIME Fixes: ccde82e909467 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Keita Morisaki Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-7-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Stable-dep-of: fa28351f970f ("ice: fix potential NULL pointer deref in error path of ice_set_ringparam()") Signed-off-by: Sasha Levin commit cbfbc9d446d982c8cd3aa45c4758486f00fe953b Author: Alexander Lobakin Date: Mon Jan 19 17:08:43 2026 +0100 ice: reshuffle and group Rx and Tx queue fields by cachelines [ Upstream commit 24f90786efaf1c573518706408deadcef189e6de ] Place the fields in ice_{rx,tx}_ring used in the same pieces of hotpath code closer to each other and use __cacheline_group_{begin,end}_aligned() to isolate the read mostly, read-write, and cold groups into separate cachelines similarly to idpf. Suggested-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Reviewed-by: Jacob Keller Signed-off-by: Alexander Lobakin Reviewed-by: Paul Menzel Signed-off-by: Tony Nguyen Only the Tx ring layout change is carried here; the Rx ring part and the next_to_alloc removal depend on the libeth Rx conversion that is not present, so they are dropped. Stable-dep-of: fa28351f970f ("ice: fix potential NULL pointer deref in error path of ice_set_ringparam()") Signed-off-by: Sasha Levin commit 349499a65b6b5fb6f66ba3673598ab558f48c544 Author: Hristo Venev Date: Mon May 4 18:54:45 2026 +0300 ceph: put folios not suitable for writeback [ Upstream commit 544576f0f05c4a759806acddfaaeb686f14fb4b0 ] The batch holds references to the folios (see `filemap_get_folios`, `folio_batch_release`), so we need to `folio_put` the folios we remove. Tested on v6.18. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/74156 Signed-off-by: Hristo Venev Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 5df268406ef38d0f92547959296577c7077dacdc Author: Raphael Zimmer Date: Tue Apr 28 14:15:46 2026 +0200 libceph: Fix potential out-of-bounds access in __ceph_x_decrypt() [ Upstream commit 821365487aa58d06bda65c676ba215d506ba9768 ] In __ceph_x_decrypt(), a part of the buffer p is interpreted as a ceph_x_encrypt_header, and the magic field of this struct is accessed. This happens without any guarantee that the buffer is large enough to hold this struct. The function parameter ciphertext_len represents the length of the ciphertext to decrypt and is guaranteed to be at most the remaining size of the allocated buffer p. However, this value is not necessarily greater than sizeof(ceph_x_encrypt_header). E.g., a message frame of type FRAME_TAG_AUTH_REPLY_MORE, that is just as long to hold the ciphertext at its end with a ciphertext_len of 8 or less, can trigger an out-of-bounds memory access when accessing hdr->magic. This patch fixes the issue by adding a check to ensure that the decrypted plaintext in the buffer is large enough to represent at least the ceph_x_encrypt_header. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit d0ce7b07dafe43d78150f90894027746576d7cb7 Author: Thomas Hellström Date: Mon May 11 18:24:43 2026 +0200 drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure [ Upstream commit 1d59f36e95f7f7134db0e313c9d787cb0adb2153 ] Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") to the ttm_bo_shrink() path. Move del_bulk_move from before the backup to after success only, using ttm_resource_del_bulk_move_unevictable() since the resource is now unevictable once fully backed up. Fixes: 70d645deac98 ("drm/ttm: Add helpers for shrinking") Cc: Christian König Cc: Huang Rui Cc: Matthew Auld Cc: Matthew Brost Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.15+ Assisted-by: GitHub_Copilot:claude-opus-4.6 Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260511162443.24352-1-thomas.hellstrom@linux.intel.com Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 060f8f3020516d71bc4d6159d4d0beef85606a74 Author: Thomas Hellström Date: Tue Apr 28 11:44:42 2026 +0200 drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure [ Upstream commit b2ed01e7ad3de80333e9b962a44024b094bc0b2b ] When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource's bulk_move membership. However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop. Fix by deferring del_bulk_move to the success path only. On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard. Reported-by: Jatin Kataria Fixes: fc5d96670eb2 ("drm/ttm: Move swapped objects off the manager's LRU list") Cc: Christian König Cc: Matthew Brost Cc: Cc: # v6.13+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Christian König Tested-by: Boqun Feng Link: https://patch.msgid.link/20260428094442.16985-1-thomas.hellstrom@linux.intel.com Stable-dep-of: 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") Signed-off-by: Sasha Levin commit dc24e03be0e4bb2aad1a9b272c4f86de3b11969a Author: D. Wythe Date: Wed Jan 28 13:54:52 2026 +0800 Revert "net/smc: Introduce TCP ULP support" [ Upstream commit df31a6b0a3057e66994ad6ccf5d95b9b9514f033 ] This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40. As reported by Al Viro, the TCP ULP support for SMC is fundamentally broken. The implementation attempts to convert an active TCP socket into an SMC socket by modifying the underlying `struct file`, dentry, and inode in-place, which violates core VFS invariants that assume these structures are immutable for an open file, creating a risk of use after free errors and general system instability. Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely. Fixes: d7cd421da9da ("net/smc: Introduce TCP ULP support") Link: https://lore.kernel.org/netdev/Yus1SycZxcd+wHwz@ZenIV/ Reported-by: Al Viro Signed-off-by: D. Wythe Reviewed-by: Tony Lu Reviewed-by: Dust Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260128055452.98251-1-alibuda@linux.alibaba.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2da62dbb4169e758c0b1a9378b39a373bf4fb111 Author: Sunil Khatri Date: Mon May 4 18:21:17 2026 +0530 drm/amdgpu/userq: fix access to stale wptr mapping [ Upstream commit 6da7b1242da4455b11c24ce667d1cab1a348c8ea ] Use drm_exec to take both locks i.e vm root bo and wptr_obj bo to access the mapping data properly. This fixes the security issue of unmap the wptr_obj while a queue creation is in progress and passing other bo at same address. Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b33d6f5da16e0eec95b933342812c689cdfcec03 Author: Ritesh Harjani (IBM) Date: Fri May 1 09:41:40 2026 +0530 pseries/papr-hvpipe: Fix race with interrupt handler [ Upstream commit 7a4f0846ee6cc8cf44ae0046ed42e3259d1dd45b ] While executing ->ioctl handler or ->release handler, if an interrupt fires on the same cpu, then we can enter into a deadlock. This patch fixes both these handlers to take spin_lock_irq{save|restore} versions of the lock to prevent this deadlock. Cc: stable@vger.kernel.org Fixes: 814ef095f12c9 ("powerpc/pseries: Add papr-hvpipe char driver for HVPIPE interfaces") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/e4ed435c44fc191f2eb23c7907ba6f72f193e6aa.1777606826.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 51a321dec76f7e39403a0574897a4409a8a700c4 Author: Christian Brauner Date: Sun Nov 23 17:33:51 2025 +0100 papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE() [ Upstream commit 6d3789d347a7af5c4b0b2da3af47b8d9da607ab2 ] Fixes a UAF for src_info as well. Link: https://patch.msgid.link/20251123-work-fd-prepare-v4-33-b6efa1706cfd@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 7a4f0846ee6c ("pseries/papr-hvpipe: Fix race with interrupt handler") Signed-off-by: Sasha Levin commit 1d15503e454bf117a0d0078332d48df86a41c828 Author: Srinivasan Shanmugam Date: Mon Oct 5 18:51:52 2026 -0400 drm/amd/display: Fix dc_link NULL handling in HPD init [ Upstream commit 226a40c06a183abaeb7529a4f54d6c203bd14407 ] amdgpu_dm_hpd_init() may see connectors without a valid dc_link. The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts. Assign dc_link early and skip connectors where it is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed 'dc_link' could be null (see line 931) drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c 923 /* 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 */ 927 use_polling |= 928 amdgpu_dm_connector->dc_link && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id); 930 931 dc_link = amdgpu_dm_connector->dc_link; dc_link assigned here. 932 933 /* 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on 937 * hpd_rx isn't available. DM currently controls hpd_rx 938 * explicitly with dc_interrupt_set() 939 */ --> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1; 942 /* 943 * TODO: There's a mismatch between mode_info.num_hpd 944 * and what bios reports as the # of connectors with hpd Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Cc: Timur Kristóf Cc: Harry Wentland Cc: Mario Limonciello Cc: Alex Hung Cc: Aurabindo Pillai Cc: ChiaHsuan Chung Cc: Roman Li Reported-by: Dan Carpenter Signed-off-by: Srinivasan Shanmugam Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 96889fcdb0988108a19a29b0467717a503651a73 Author: Vishnu Reddy Date: Thu Mar 5 18:58:31 2026 +0530 media: iris: fix use-after-free of fmt_src during MBPF check [ Upstream commit 3d9593ad1a58c5acc3e5fa2a48222bb7632e6812 ] During concurrency testing, multiple instances can run in parallel, and each instance uses its own inst->lock while the core->lock protects the list of active instances. The race happens because these locks cover different scopes, inst->lock protects only the internals of a single instance, while the Macro Blocks Per Frame (MBPF) checker walks the core list under core->lock and reads fields like fmt_src->width and fmt_src->height. At the same time, iris_close() may free fmt_src and fmt_dst under inst->lock while the instance is still present in the core list. This allows a situation where the MBPF checker, still iterating through the core list, reaches an instance whose fmt_src was already freed by another thread and ends up dereferencing a dangling pointer, resulting in a use-after-free. This happens because the MBPF checker assumes that any instance in the core list is fully valid, but the freeing of fmt_src and fmt_dst without removing the instance from the core list is not correct. The correct ordering is to defer freeing fmt_src and fmt_dst until after the instance has been removed from the core list and all teardown under the core lock has completed, ensuring that no dangling pointers are ever exposed during MBPF checks. Reviewed-by: Vikash Garodia Signed-off-by: Vishnu Reddy Reviewed-by: Dikshita Agarwal Fixes: 5ad964ad5656 ("media: iris: Initialize and deinitialize encoder instance structure") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 46edfdcf95d2bdfb53f9394776b0733e37ec45ac Author: Dmitry Baryshkov Date: Tue Oct 28 13:46:20 2025 +0200 media: iris: turn platform caps into constants [ Upstream commit e5894eeefdebf5a6d7512cd23efec78071985738 ] Make all struct platform_inst_fw_cap instances constant, they are not modified at runtime. Reviewed-by: Bryan O'Donoghue Reviewed-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Signed-off-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Stable-dep-of: 3d9593ad1a58 ("media: iris: fix use-after-free of fmt_src during MBPF check") Signed-off-by: Sasha Levin commit b0eb0a8959ac2b808eb11548d002fe1f9b5650cc Author: Yosry Ahmed Date: Tue Mar 3 00:34:03 2026 +0000 KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT [ Upstream commit 5d291ef0585ed880ed4dd71ea1a5965e0a65fb53 ] If loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nested_svm_vmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible. From the APM: Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context: ... if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway. Fixes: d82aaef9c88a ("KVM: nSVM: use nested_svm_load_cr3() on guest->host switch") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-10-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 73df74544b55241dca5dd788523e6f5f10bd2b9b Author: Seohyeon Maeng Date: Tue Mar 10 17:16:52 2026 +0900 udf: fix partition descriptor append bookkeeping [ Upstream commit 08841b06fa64d8edbd1a21ca6e613420c90cc4b8 ] Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model. Fixes: ee4af50ca94f ("udf: Fix mounting of Win7 created UDF filesystems") Cc: stable@vger.kernel.org Signed-off-by: Seohyeon Maeng Link: https://patch.msgid.link/20260310081652.21220-1-bioloidgp@gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 4456be93464a599eac0eb2afa63b5d662e1599d8 Author: Deepanshu Kartikey Date: Tue Feb 3 07:50:33 2026 +0530 gfs2: fix memory leaks in gfs2_fill_super error path [ Upstream commit da6f5bbc2e7902f578b503f2a4c3d8d09ca4b102 ] Fix two memory leaks in the gfs2_fill_super() error handling path when transitioning a filesystem to read-write mode fails. First leak: kthread objects (thread_struct, task_struct, etc.) When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the fail_per_node label doesn't call gfs2_destroy_threads(). Second leak: quota bitmap buffer (8192 bytes) When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed. The fix moves thread cleanup to the fail_per_node label to handle all error paths uniformly. gfs2_destroy_threads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2_make_fs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn. Thread leak backtrace (gfs2_freeze_lock_shared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copy_process+0x3a1/0x4670 kernel/fork.c:2422 kernel_clone+0xf3/0x6e0 kernel/fork.c:2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c:478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265 Quota leak backtrace (gfs2_make_fs_rw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275 Reported-by: syzbot+aac438d7a1c44071e04b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=aac438d7a1c44071e04b Fixes: 6c7410f44961 ("gfs2: gfs2_freeze_lock_shared cleanup") Fixes: b66f723bb552 ("gfs2: Improve gfs2_make_fs_rw error handling") Link: https://lore.kernel.org/all/20260131062509.77974-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 370154a83a835a515386af393aa6cd95842859d2 Author: Andreas Gruenbacher Date: Wed Aug 6 17:30:40 2025 +0200 gfs2: Rename gfs2_{withdrawing_or_ => }withdrawn [ Upstream commit 1b7d498dcab489c4bcbc46870264fbeaf81c16e7 ] With delayed withdraws and the SDF_WITHDRAWING flag gone, we can now rename gfs2_withdrawing_or_withdrawn() back to gfs2_withdrawn(). Signed-off-by: Andreas Gruenbacher Stable-dep-of: da6f5bbc2e79 ("gfs2: fix memory leaks in gfs2_fill_super error path") Signed-off-by: Sasha Levin commit 1b6a9f81c47150d19524aa4a710c38852bf09f3f Author: Andreas Gruenbacher Date: Tue Aug 5 23:32:39 2025 +0200 gfs2: Get rid of delayed withdraws [ Upstream commit 8daf6c2b3d8ceea5559cceb8ed7e1275ee72a7be ] Now that gfs2_withdraw() is asynchronous, is can be called in any context and there is no more need for gfs2_withdraw_delayed() or for turning delayed withdraws into actual withdraws. Remove the now-obsolete code. Signed-off-by: Andreas Gruenbacher Stable-dep-of: da6f5bbc2e79 ("gfs2: fix memory leaks in gfs2_fill_super error path") Signed-off-by: Sasha Levin commit dfd14e14772c65fcabb7630236344e3b86eae09d Author: Andreas Gruenbacher Date: Tue Aug 5 23:12:06 2025 +0200 gfs2: Asynchronous withdraw [ Upstream commit 9c4a3de6cd5b46aa743c460b86eb58fe5f93daec ] So far, withdraws are carried out in the context of the calling task. When another task tries to withdraw while a withdraw is already underway, that task blocks as well. Change that to carry out withdraws asynchronously in workqueue context and don't block the task triggering the withdraw anymore. Fixes: syzbot+6b156e132970e550194c@syzkaller.appspotmail.com Signed-off-by: Andreas Gruenbacher Stable-dep-of: da6f5bbc2e79 ("gfs2: fix memory leaks in gfs2_fill_super error path") Signed-off-by: Sasha Levin commit 604dca7c20a151454a9870b980827d2f69f80968 Author: Andreas Gruenbacher Date: Thu Jul 17 02:03:28 2025 +0200 gfs2: Add clean argument to lm_unmount hook [ Upstream commit 9334c73fb16b183a6d4af09ce1d445f7f89b8d49 ] Add a 'clean' argument to ->lm_unmount() that indicates whether the filesystem is clean or needs recovery. Set clean to true for normal unmounts, and to false for withdraws. Signed-off-by: Andreas Gruenbacher Stable-dep-of: da6f5bbc2e79 ("gfs2: fix memory leaks in gfs2_fill_super error path") Signed-off-by: Sasha Levin commit 74b981f0d3b9056acc22aaa0ba61e46c08c0bb2c Author: Andreas Gruenbacher Date: Wed Nov 26 23:32:33 2025 +0000 gfs2: Clean up quotad timeout handling [ Upstream commit 94f56488c7e47579aae8f20323c43d27b7b5f4ef ] Instead of tracking the remaining time, track the deadline of each of the timeouts. Signed-off-by: Andreas Gruenbacher Stable-dep-of: da6f5bbc2e79 ("gfs2: fix memory leaks in gfs2_fill_super error path") Signed-off-by: Sasha Levin commit 9e0652e243ef4922d3776f795c559b54e8593315 Author: Utkarsh Singh Date: Mon Sep 22 23:22:22 2025 +0530 gfs2/sysfs: Replace sprintf/snprintf with sysfs_emit [ Upstream commit 02c03021e2fced59b3b5b200fdd00018725d4ee2 ] Documentation/filesystems/sysfs.rst mentions that show() should only use sysfs_emit() or sysfs_emit_at() when formatting values returned to user space. This patch updates the GFS2 sysfs interface accordingly. It replaces uses of sprintf() and snprintf() in all *_show() functions with sysfs_emit() to align with current kernel sysfs API best practices. It also updates the TUNE_ATTR_2 macro to use sysfs_emit() instead of snprintf(). Signed-off-by: Utkarsh Singh Signed-off-by: Andreas Gruenbacher Stable-dep-of: da6f5bbc2e79 ("gfs2: fix memory leaks in gfs2_fill_super error path") Signed-off-by: Sasha Levin commit e0e31a7ed1191c12a28763bb70c4c7f5adadc79d Author: Chen Ni Date: Tue Mar 10 12:43:27 2026 +0800 ASoC: amd: acp-mach-common: Add missing error check for clock acquisition [ Upstream commit 30c64fb9839949f085c8eb55b979cbd8a4c51f00 ] The acp_card_rt5682_init() and acp_card_rt5682s_init() functions did not check the return values of clk_get(). This could lead to a kernel crash when the invalid pointers are later dereferenced by clock core functions. Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding IS_ERR() checks immediately after each clock acquisition. Fixes: 8b7256266848 ("ASoC: amd: acp: Add support for RT5682-VS codec") Fixes: d4c750f2c7d4 ("ASoC: amd: acp: Add generic machine driver support for ACP cards") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260310044327.2582018-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4097a2afe8acc6038b71aab825430f1403decf20 Author: Vladimir Riabchun Date: Tue Feb 10 11:08:22 2026 +0100 scsi: qla2xxx: Completely fix fcport double free [ Upstream commit c0b7da13a04bd70ef6070bfb9ea85f582294560a ] In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea. Fixes: 82f522ae0d97 ("scsi: qla2xxx: Fix double free of fcport") Fixes: 4895009c4bb7 ("scsi: qla2xxx: Prevent command send on chip reset") Signed-off-by: Vladimir Riabchun Signed-off-by: Farhat Abbas Link: https://patch.msgid.link/aYsDln9NFQQsPDgg@vova-pc Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 57a79c5df057deb7c1d0ebc066698c795092530f Author: Prathamesh Shete Date: Thu Jan 8 05:01:03 2026 +0000 soc/tegra: pmc: Fix unsafe generic_handle_irq() call [ Upstream commit e6d96073af681780820c94079b978474a8a44413 ] Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. Signed-off-by: Petlozu Pravareshwar Signed-off-by: Prathamesh Shete Reviewed-by: Jon Hunter Tested-by: Jon Hunter [treding@nvidia.com: miscellaneous cleanups] Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5133ef7c893c2c3aee7dd12503dc480de9dbfbb5 Author: Ming Qian Date: Fri Dec 5 09:54:26 2025 +0800 media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC [ Upstream commit e0203ddf9af7c8e170e1e99ce83b4dc07f0cd765 ] For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and g2 VPU cannot decode simultaneously; otherwise, it will cause below bus error and produce corrupted pictures, even potentially lead to system hang. [ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out. [ 110.583517] hantro-vpu 38310000.video-codec: bus error detected. Therefore, it is necessary to ensure that g1 and g2 operate alternately. This allows for successful multi-instance decoding of H.264 and HEVC. To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then the v4l2_m2m_dev can handle the scheduling. Fixes: cb5dd5a0fa518 ("media: hantro: Introduce G2/HEVC decoder") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Frank Li Co-developed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6c5d98f24f99596c0075c05d17b099d298f0246b Author: Nicolas Dufresne Date: Fri Dec 5 09:54:24 2025 +0800 media: v4l2-mem2mem: Add a kref to the v4l2_m2m_dev structure [ Upstream commit db6b97a4f8041e479be9ef4b8b07022636c96f50 ] Adding a reference count to the v4l2_m2m_dev structure allow safely sharing it across multiple hardware nodes. This can be used to prevent running jobs concurrently on m2m cores that have some internal resource sharing. Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [hverkuil: fix typos in v4l2_m2m_put documentation] Stable-dep-of: e0203ddf9af7 ("media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC") Signed-off-by: Sasha Levin commit 6ad4caadc6343c3d7987bf3211f15d66135c4c42 Author: Filipe Manana Date: Tue Jan 13 16:37:26 2026 +0000 btrfs: don't BUG() on unexpected delayed ref type in run_one_delayed_ref() [ Upstream commit c7d1d4ff56744074e005771aff193b927392d51f ] There is no need to BUG(), we can just return an error and log an error message. Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6311ee6daa9ccbc90b0263ce97081ef9c0df9bac Author: Filipe Manana Date: Mon Oct 20 13:48:33 2025 +0100 btrfs: remove 'reserved' argument from btrfs_pin_extent() [ Upstream commit 8dcb8e4b110d86aaae2c485622423b6f63a65408 ] All callers pass a value of 1 (true) to it, so remove it. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: c7d1d4ff5674 ("btrfs: don't BUG() on unexpected delayed ref type in run_one_delayed_ref()") Signed-off-by: Sasha Levin commit 81e1ae665004b99a10686473d99f0a7cb6335f38 Author: Qu Wenruo Date: Tue Jan 27 15:46:55 2026 +1030 btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure() [ Upstream commit 8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3 ] [BUG] There is a bug report that when btrfs hits ENOSPC error in a critical path, btrfs flips RO (this part is expected, although the ENOSPC bug still needs to be addressed). The problem is after the RO flip, if there is a read repair pending, we can hit the ASSERT() inside btrfs_repair_io_failure() like the following: BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -28) WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844 Modules linked in: kvm_intel kvm irqbypass [...] ---[ end trace 0000000000000000 ]--- BTRFS info (device vdc state EA): 2 enospc errors during balance BTRFS info (device vdc state EA): balance: ended with status: -30 BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6 BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0 [...] assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 ------------[ cut here ]------------ assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 kernel BUG at fs/btrfs/bio.c:938! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full) Tainted: [W]=WARN, [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: btrfs-endio simple_end_io_work RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120 RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988 R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310 R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000 FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ------------[ cut here ]------------ [CAUSE] The cause of -ENOSPC error during the test case btrfs/124 is still unknown, although it's known that we still have cases where metadata can be over-committed but can not be fulfilled correctly, thus if we hit such ENOSPC error inside a critical path, we have no choice but abort the current transaction. This will mark the fs read-only. The problem is inside the btrfs_repair_io_failure() path that we require the fs not to be mount read-only. This is normally fine, but if we are doing a read-repair meanwhile the fs flips RO due to a critical error, we can enter btrfs_repair_io_failure() with super block set to read-only, thus triggering the above crash. [FIX] Just replace the ASSERT() with a proper return if the fs is already read-only. Reported-by: Christoph Hellwig Link: https://lore.kernel.org/linux-btrfs/20260126045555.GB31641@lst.de/ Tested-by: Christoph Hellwig Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 559f856b109c45844816a1693e259f93d3556c61 Author: Jori Koolstra Date: Sat Dec 20 20:10:06 2025 +0100 hfs: Replace BUG_ON with error handling for CNID count checks [ Upstream commit b226804532a875c10276168dc55ce752944096bd ] In a06ec283e125 next_id, folder_count, and file_count in the super block info were expanded to 64 bits, and BUG_ONs were added to detect overflow. This triggered an error reported by syzbot: if the MDB is corrupted, the BUG_ON is triggered. This patch replaces this mechanism with proper error handling and resolves the syzbot reported bug. Singed-off-by: Jori Koolstra Reported-by: syzbot+17cc9bb6d8d69b4139f0@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=17cc9bb6d8d69b4139f0 Signed-off-by: Jori Koolstra Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251220191006.2465256-1-jkoolstra@xs4all.nl Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 3a409a64b2d61430c63cbb15d51681f13b8b0acd Author: Cédric Bellegarde Date: Fri Jan 2 22:52:25 2026 +0100 ASoC: qcom: q6asm: drop DSP responses for closed data streams [ Upstream commit 8a066a81ee0c1b6cdbd81393536c3b2d19ccef25 ] 'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses after closing")' attempted to ignore DSP responses arriving after a stream had been closed. However, those responses were still handled, causing lockups. Fix this by unconditionally dropping all DSP responses associated with closed data streams. Signed-off-by: Cédric Bellegarde Link: https://patch.msgid.link/20260102215225.609166-1-cedric.bellegarde@adishatz.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d9bf525dff80bf384c272ed6b74a7646e407111d Author: Srinivas Kandagatla Date: Thu Oct 23 11:24:29 2025 +0100 ASoC: qcom: q6asm: handle the responses after closing [ Upstream commit a354f030dbce17ab3cf299660a38b162d97f7151 ] For record path, multiple read requests are queued to dsp in advance. However when data stream is closed, the pending read requests are rejected by the dsp and a response is sent to the driver, this case is not handled in the driver resulting in errors like below q6asm-dai ab00000.remoteproc:glink-edge:apr:service@7:dais: command[0x10dac] not expecting rsp q6asm-dai ab00000.remoteproc:glink-edge:apr:service@7:dais: command[0x10dac] not expecting rsp q6asm-dai ab00000.remoteproc:glink-edge:apr:service@7:dais: command[0x10dac] not expecting rsp This is same for both write and eos. Fix this by allowing ASM_DATA_CMD_READ_V2, ASM_DATA_CMD_EOS and ASM_DATA_CMD_WRITE_V2 as expected response. Reported-by: Martino Facchin Signed-off-by: Srinivas Kandagatla Tested-by: Alexey Klimov # RB5, RB3 Link: https://patch.msgid.link/20251023102444.88158-6-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Stable-dep-of: 8a066a81ee0c ("ASoC: qcom: q6asm: drop DSP responses for closed data streams") Signed-off-by: Sasha Levin commit 02b033e18e08a1d0b53cf540196688c82af60a2f Author: Nicholas Kazlauskas Date: Wed Dec 17 13:21:59 2025 -0500 drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35 [ Upstream commit 75372d75a4e23783583998ed99d5009d555850da ] [Why] A backport of the change made for DCN401 that addresses an issue where we turn off the PHY PLL when disabling TMDS output, which causes the OTG to remain stuck. The OTG being stuck can lead to a hang in the DCHVM's ability to ACK invalidations when it thinks the HUBP is still on but it's not receiving global sync. The transition to PLL_ON needs to be atomic as there's no guarantee that the thread isn't pre-empted or is able to complete before the IOMMU watchdog times out. [How] Backport the implementation from dcn401 back to dcn35. There's a functional difference in when the eDP output is disabled in dcn401 code so we don't want to utilize it directly. Reviewed-by: Yihan Zhu Signed-off-by: Nicholas Kazlauskas Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 203a9241a738459d9ef764c3fee7f7445d790eec Author: Nicholas Kazlauskas Date: Wed Sep 17 13:00:58 2025 -0400 drm/amd/display: Rename FAMS2 global control lock to DMUB HW control lock [ Upstream commit 6d92c4d03063480a60bbc3ff61d22197c931f411 ] [Why] FAMS2 dictates whether the inbox0 HW lock is required, but it is not the only feature that may determine this. In order to leverage the faster inbox0 HW lock in place of the inbox1 ringbuffer based control lock it's desirable to utilize the HWSS based locking protocol FAMS2 has already implemented. [How] Rename the FAMS2 global control lock to DMUB HW control lock. This is purely a refactor with no functional change, the logic that will determine which features need to enable this HW lock will be added in a future commit. Reviewed-by: Alvin Lee Signed-off-by: Nicholas Kazlauskas Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 75372d75a4e2 ("drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35") Signed-off-by: Sasha Levin commit 28768bc7ea0b13f558a70f63cc3cfcd32d55d488 Author: Joel Fernandes Date: Mon Mar 23 20:14:18 2026 -0400 srcu: Use irq_work to start GP in tiny SRCU [ Upstream commit a6fc88b22bc8d12ad52e8412c667ec0f5bf055af ] Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(), which acquires the workqueue pool->lock. This causes a lockdep splat when call_srcu() is called with a scheduler lock held, due to: call_srcu() [holding pi_lock] srcu_gp_start_if_needed() schedule_work() -> pool->lock workqueue_init() / create_worker() [holding pool->lock] wake_up_process() -> try_to_wake_up() -> pi_lock Also add irq_work_sync() to cleanup_srcu_struct() to prevent a use-after-free if a queued irq_work fires after cleanup begins. Tested with rcutorture SRCU-T and no lockdep warnings. [ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work to start process_srcu()" ] Signed-off-by: Joel Fernandes Reviewed-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 37419fa1b0bc21ed7de29a76d97f5bf4a4885a1b Author: Thomas Gleixner Date: Wed Nov 19 18:27:18 2025 +0100 irqwork: Move data struct to a types header [ Upstream commit c809f081fe400cb1b9898f4791c0d33146315161 ] ... to avoid header recursion hell. Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Reviewed-by: Mathieu Desnoyers Link: https://patch.msgid.link/20251119172550.152813625@linutronix.de Signed-off-by: Sasha Levin commit d14847cb7f65d419e43451d416a1f50c09a5f3be Author: Stanislav Kinsburskii Date: Tue Mar 17 15:04:55 2026 +0000 mshv: Fix error handling in mshv_region_pin [ Upstream commit c0e296f257671ba10249630fe58026f29e4804d9 ] The current error handling has two issues: First, pin_user_pages_fast() can return a short pin count (less than requested but greater than zero) when it cannot pin all requested pages. This is treated as success, leading to partially pinned regions being used, which causes memory corruption. Second, when an error occurs mid-loop, already pinned pages from the current batch are not properly accounted for before calling mshv_region_invalidate_pages(), causing a page reference leak. Treat short pins as errors and fix partial batch accounting before cleanup. Signed-off-by: Stanislav Kinsburskii Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit f33de03b47c14445d911f938542b243d22c25295 Author: Stanislav Kinsburskii Date: Wed Dec 3 21:40:50 2025 +0000 mshv: Move region management to mshv_regions.c [ Upstream commit e950c30a1051d27fd6dd9a48c53ffbc41ee773f2 ] Refactor memory region management functions from mshv_root_main.c into mshv_regions.c for better modularity and code organization. Adjust function calls and headers to use the new implementation. Improve maintainability and separation of concerns in the mshv_root module. Signed-off-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Reviewed-by: Nuno Das Neves Signed-off-by: Wei Liu Stable-dep-of: c0e296f25767 ("mshv: Fix error handling in mshv_region_pin") Signed-off-by: Sasha Levin commit 06c0ce18055a55479d8a9edb18cc7eb1b5589ff0 Author: Stanislav Kinsburskii Date: Wed Dec 3 21:40:45 2025 +0000 mshv: Centralize guest memory region destruction [ Upstream commit 6f6aed2c497e8d80d8ed6b5a87c6f65dc7548b8f ] Centralize guest memory region destruction to prevent resource leaks and inconsistent cleanup across unmap and partition destruction paths. Unify region removal, encrypted partition access recovery, and region invalidation to improve maintainability and reliability. Reduce code duplication and make future updates less error-prone by encapsulating cleanup logic in a single helper. Signed-off-by: Stanislav Kinsburskii Reviewed-by: Nuno Das Neves Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Stable-dep-of: c0e296f25767 ("mshv: Fix error handling in mshv_region_pin") Signed-off-by: Sasha Levin commit 93ed80634288d24116074e786a582092ca314782 Author: Stanislav Kinsburskii Date: Wed Dec 3 21:40:39 2025 +0000 mshv: Refactor and rename memory region handling functions [ Upstream commit df4ff5f6cf7864714d66c65ec7df582240a596a4 ] Simplify and unify memory region management to improve code clarity and reliability. Consolidate pinning and invalidation logic, adopt consistent naming, and remove redundant checks to reduce complexity. Enhance documentation and update call sites for maintainability. Signed-off-by: Stanislav Kinsburskii Reviewed-by: Nuno Das Neves Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Stable-dep-of: c0e296f25767 ("mshv: Fix error handling in mshv_region_pin") Signed-off-by: Sasha Levin commit a40a75df332671866113cf7691bd464b39757e3f Author: Naman Jain Date: Thu Nov 13 04:41:47 2025 +0000 static_call: allow using STATIC_CALL_TRAMP_STR() from assembly [ Upstream commit 796ef5a7fe86a8605f2844471ed7baa8e80bace8 ] STATIC_CALL_TRAMP_STR() could not be used from .S files because static_call_types.h was not safe to include in assembly as it pulled in C types/constructs that are unavailable under __ASSEMBLY__. Make the header assembly-friendly by adding __ASSEMBLY__ checks and providing only the minimal definitions needed for assembly, so that it can be safely included by .S code. This enables emitting the static call trampoline symbol name via STATIC_CALL_TRAMP_STR() directly in assembly sources, to be used with 'call' instruction. Also, move a certain definitions out of __ASSEMBLY__ checks in compiler_types.h to meet the dependencies. No functional change for C compilation. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Naman Jain Signed-off-by: Wei Liu Stable-dep-of: c0e296f25767 ("mshv: Fix error handling in mshv_region_pin") Signed-off-by: Sasha Levin commit 5cfa4f537a056c91ac6c09bc3ab58a4455217df7 Author: Pauli Virtanen Date: Wed Mar 25 21:07:43 2026 +0200 Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists [ Upstream commit 2969554bcfccb5c609f6b6cd4a014933f3a66dd0 ] hci_cmd_sync_queue_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources. Change the function to return -EEXIST if queue item already exists. Modify all callsites to handle that. Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 971854e7b6ddda78669d3d0cf6566c7b8aca1fdb Author: Takashi Iwai Date: Sun Mar 29 11:12:38 2026 +0200 ALSA: ctxfi: Check the error for index mapping [ Upstream commit 277c6960d4ddb94d16198afd70c92c3d4593d131 ] The ctxfi driver blindly assumed a proper value returned from daio_device_index(), but it's not always true. Add a proper error check to deal with the error from the function. Cc: Link: https://lore.kernel.org/87cy149n6k.wl-tiwai@suse.de Link: https://patch.msgid.link/20260329091240.420194-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 88cc09bb70651917ef8b7095a05a21a9ca014c94 Author: Harin Lee Date: Tue Nov 25 03:04:59 2025 +0900 ALSA: ctxfi: Refactor resource alloc for sparse mappings [ Upstream commit a2dbaeb5c61ef110ceefe0d48fe94d428d3bcf16 ] Refactor atc_get_resources(), atc_connect_resources(), and atc_release_resources() to allocate resources based on maximum type definitions. This allows specific resources to be conditionally skipped based on capabilities. This is necessary for hardware variants where resource allocations do not follow a sequential order. Signed-off-by: Harin Lee Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251124180501.2760421-5-me@harin.net Stable-dep-of: 277c6960d4dd ("ALSA: ctxfi: Check the error for index mapping") Signed-off-by: Sasha Levin commit 1422b94887c5cb97dc37661b1f025831dce64bd8 Author: Harin Lee Date: Tue Nov 25 03:04:58 2025 +0900 ALSA: ctxfi: Use explicit output flag for DAIO resources [ Upstream commit 9bb003a1f98b11b80238d522778115ad07355149 ] Replace the index-based type check with an explicit output flag in struct daio and struct daio_desc. This allows handling DAIO resource types correctly regardless of their index. This is necessary for hardware variants where resource types do not follow a sequential order. Signed-off-by: Harin Lee Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251124180501.2760421-4-me@harin.net Stable-dep-of: 277c6960d4dd ("ALSA: ctxfi: Check the error for index mapping") Signed-off-by: Sasha Levin commit c0904c424f7da716bda8ecbdd48ec068ee039719 Author: Harin Lee Date: Tue Nov 25 03:04:56 2025 +0900 ALSA: ctxfi: Add hw parameter to daio_mgr_dao_init() [ Upstream commit 5ebd054272718334c543998a6d0b77a9846c16d9 ] Add a hw parameter to the daio_mgr_dao_init() function to provide access to model-specific information. This is necessary for proper configuration of S/PDIF and I2S output ports on different hardware variants. Signed-off-by: Harin Lee Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251124180501.2760421-2-me@harin.net Stable-dep-of: 277c6960d4dd ("ALSA: ctxfi: Check the error for index mapping") Signed-off-by: Sasha Levin commit dbc8b8d33c9e19e17e8b8b1361bbb46e2983f5f2 Author: Oleh Konko Date: Thu Mar 26 17:31:24 2026 +0000 Bluetooth: hci_event: move wake reason storage into validated event handlers [ Upstream commit 2b2bf47cd75518c36fa2d41380e4a40641cc89cd ] hci_store_wake_reason() is called from hci_event_packet() immediately after stripping the HCI event header but before hci_event_func() enforces the per-event minimum payload length from hci_ev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs. Rather than duplicating skb parsing and per-event length checks inside hci_store_wake_reason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hci_store_wake_reason() into a small helper that only stores an already-validated bdaddr while the caller holds hci_dev_lock(). Use the same helper after hci_event_func() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address. Annotate the helper with __must_hold(&hdev->lock) and add lockdep_assert_held(&hdev->lock) so future call paths keep the lock contract explicit. Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(), hci_sync_conn_complete_evt(), le_conn_complete_evt(), hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(), hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and hci_le_past_received_evt(). Fixes: 2f20216c1d6f ("Bluetooth: Emit controller suspend and resume events") Cc: stable@vger.kernel.org Signed-off-by: Oleh Konko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c516c2e06fe580b8d38de60cd407072a5de81506 Author: David Carlier Date: Fri Mar 20 17:44:39 2026 +0000 net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path [ Upstream commit eb8c426c9803beb171f89d15fea17505eb517714 ] cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor. In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is freed via k3_cppi_desc_pool_free() before the psdata pointer is used by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1]. This constitutes a use-after-free on every received packet that goes through the timestamp path. Defer the descriptor free until after all accesses through the psdata pointer are complete. For emac_rx_packet(), move the free into the requeue label so both early-exit and success paths free the descriptor after all accesses are done. For emac_rx_packet_zc(), move the free to the end of the loop body after emac_dispatch_skb_zc() (which calls emac_rx_timestamp()) has returned. Fixes: 46eeb90f03e0 ("net: ti: icssg-prueth: Use page_pool API for RX buffer allocation") Signed-off-by: David Carlier Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260320174439.41080-1-devnexen@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2352d719cccfccf918e466deee6fd59c4ecf0376 Author: Meghana Malladi Date: Tue Nov 18 19:25:40 2025 +0530 net: ti: icssg-prueth: Make emac_run_xdp function independent of page [ Upstream commit 121133163c9ff0d1e6a2f7d4a461e535088fc2e3 ] emac_run_xdp function runs xdp program, at a given hook point in the Rx path of the driver in NAPI context and returns XDP return codes. In zero copy mode the driver receives packets using UMEM frames instead of pages (native XDP). Decouple the usage of page in this function. Reviewed-by: Jacob Keller Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20251118135542.380574-5-m-malladi@ti.com Signed-off-by: Paolo Abeni Stable-dep-of: eb8c426c9803 ("net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path") Signed-off-by: Sasha Levin commit 2157742f5c32f217a1adc3a5070157df32185689 Author: Meghana Malladi Date: Tue Nov 18 19:25:37 2025 +0530 net: ti: icssg-prueth: Add functions to create and destroy Rx/Tx queues [ Upstream commit 41dde7f1d01343ebebe265edd8f4b59bca591db8 ] Each port for a given ICSSG instance has their own set of Tx and Rx queues. Add functions to create and destroy these queues, which will be further used while performing ndo_bpf operations to set up XSK Tx/Rx queues for a given port. In the destroy Rx queue sequence add teardown wait to ensure that all the descriptors including the TDCM (teardown completion marker) have been serviced and freed to avoid any sort of descriptor leaks. Reviewed-by: Jacob Keller Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20251118135542.380574-2-m-malladi@ti.com Signed-off-by: Paolo Abeni Stable-dep-of: eb8c426c9803 ("net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path") Signed-off-by: Sasha Levin commit 41f3fa0d14bb86556a4fe5aca069c73b9ce2264d Author: Vadim Fedorenko Date: Thu Oct 16 15:25:10 2025 +0000 ti: icssg: convert to ndo_hwtstamp API [ Upstream commit b8fa98ea4a22d949e92ebc755abc5e633db88bf9 ] Convert driver to use .ndo_hwtstamp_get()/.ndo_hwtstamp_set() API. .ndo_eth_ioctl() implementation becomes pure phy_do_ioctl(), remove it from common module, remove exported symbol and replace ndo callback. Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Signed-off-by: Vadim Fedorenko Link: https://patch.msgid.link/20251016152515.3510991-3-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Stable-dep-of: eb8c426c9803 ("net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path") Signed-off-by: Sasha Levin commit 6e5c3ddf17a2cb1722301bbbd15655fcc20ed1ce Author: Chaitanya Kulkarni Date: Sun Mar 1 16:22:07 2026 -0800 blktrace: fix __this_cpu_read/write in preemptible context [ Upstream commit da46b5dfef48658d03347cda21532bcdbb521e67 ] tracing_record_cmdline() internally uses __this_cpu_read() and __this_cpu_write() on the per-CPU variable trace_cmdline_save, and trace_save_cmdline() explicitly asserts preemption is disabled via lockdep_assert_preemption_disabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probe_wakeup_sched_switch() / probe_wakeup()). __blk_add_trace() was calling tracing_record_cmdline(current) early in the blk_tracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002: blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message) [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 [ 81.362895] check_preemption_disabled+0xce/0xe0 [ 81.362902] tracing_record_cmdline+0x10/0x40 [ 81.362923] __blk_add_trace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30 [ 81.362959] blk_add_trace_bio+0x106/0x1e0 [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0 [ 81.362979] ? lockdep_init_map_type+0x58/0x260 [ 81.362988] submit_bio_wait+0x56/0x90 [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250 [ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10 [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0 [ 81.363051] blkdev_read_iter+0xc1/0x140 [ 81.363059] vfs_read+0x20b/0x330 [ 81.363083] ksys_read+0x67/0xe0 [ 81.363090] do_syscall_64+0xbf/0xf00 [ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(), and blk_add_trace_rq() paths as well. The purpose of tracing_record_cmdline() is to cache the task->comm for a given PID so that the trace can later resolve it. It is only meaningful when a trace event is actually being recorded. Ring buffer reservation via ring_buffer_lock_reserve() disables preemption, and preemption remains disabled until the event is committed :- __blk_add_trace() __trace_buffer_lock_reserve() __trace_buffer_lock_reserve() ring_buffer_lock_reserve() preempt_disable_notrace(); <--- With this fix blktests for blktrace pass: blktests (master) # ./check blktrace blktrace/001 (blktrace zone management command tracing) [passed] runtime 3.650s ... 3.647s blktrace/002 (blktrace ftrace corruption with sysfs trace) [passed] runtime 0.411s ... 0.384s Fixes: 7ffbd48d5cab ("tracing: Cache comms only after an event occurred") Reported-by: Shinichiro Kawasaki Suggested-by: Steven Rostedt Signed-off-by: Chaitanya Kulkarni Reviewed-by: Steven Rostedt (Google) Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6b3546e3a8c664fb8b97f587fd268dc6e413d79b Author: Lizhi Hou Date: Thu Feb 26 13:38:57 2026 -0800 accel/amdxdna: Fix NULL pointer dereference of mgmt_chann [ Upstream commit 6270ee26e1edd862ea17e3eba148ca8fb2c99dc9 ] mgmt_chann may be set to NULL if the firmware returns an unexpected error in aie2_send_mgmt_msg_wait(). This can later lead to a NULL pointer dereference in aie2_hw_stop(). Fix this by introducing a dedicated helper to destroy mgmt_chann and by adding proper NULL checks before accessing it. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260226213857.3068474-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 2f62f8be57882c26f8bede0cab293d013964208f Author: Haotian Zhang Date: Mon Nov 10 12:04:46 2025 +0800 PCI: endpoint: Add missing NULL check for alloc_workqueue() [ Upstream commit 03f336a869b3a3f119d3ae52ac9723739c7fb7b6 ] alloc_workqueue() can return NULL on memory allocation failure. Without proper error checking, this may lead to a NULL pointer dereference when queue_work() is later called with the NULL workqueue pointer in epf_ntb_epc_init(). Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on failure to prevent the driver from loading with an invalid workqueue pointer. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251110040446.2065-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit b0d908230b3d81f0186caef29c9d6152498c7748 Author: Marco Crivellari Date: Fri Nov 7 15:25:26 2025 +0100 PCI: Add WQ_PERCPU to alloc_workqueue() users [ Upstream commit 78f5d0d5a23dd81106cbe999d9dcd522964a8f1a ] Currently work items enqueued by schedule_delayed_work() use "system_wq" (a per-CPU wq), while queue_delayed_work() uses WORK_CPU_UNBOUND (used when a CPU is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they're needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue() flag in: 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Add WQ_PERCPU to explicitly request alloc_workqueue() to be per-CPU when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn't explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari [bhelgaas: squash similar commits] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251107142526.234685-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107142835.237636-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143108.240025-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143335.242342-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143624.244978-1-marco.crivellari@suse.com Stable-dep-of: 03f336a869b3 ("PCI: endpoint: Add missing NULL check for alloc_workqueue()") Signed-off-by: Sasha Levin commit b569ff8a1bc1bcd4fdc6fd334604a654f61237a1 Author: Lizhi Hou Date: Fri Dec 12 10:32:44 2025 -0800 accel/amdxdna: Fix potential NULL pointer dereference in context cleanup [ Upstream commit 97f27573837ef96b4ba42af463cc800cab615c0e ] aie_destroy_context() is invoked during error handling in aie2_create_context(). However, aie_destroy_context() assumes that the context's mailbox channel pointer is non-NULL. If mailbox channel creation fails, the pointer remains NULL and calling aie_destroy_context() can lead to a NULL pointer dereference. In aie2_create_context(), replace aie_destroy_context() with a function which request firmware to remove the context created previously. Fixes: be462c97b7df ("accel/amdxdna: Add hardware context") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251212183244.1826318-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 09ed30edcfa1f2ad0b4ff5e82ffa416eb1e2259c Author: Lizhi Hou Date: Mon Nov 3 22:25:43 2025 -0800 accel/amdxdna: Add hardware specific attributes [ Upstream commit c48f1f459e4227abbb88271e2717235de575b22e ] Add three hardware specific attributes to describe device capabilities: hwctx_limit: The maximum number of hardware context supported. max_tops: The maximum TOPS supported. curr_tops: The TOPS achievable with the current power and frequency configuration. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251104062546.833771-1-lizhi.hou@amd.com Stable-dep-of: 97f27573837e ("accel/amdxdna: Fix potential NULL pointer dereference in context cleanup") Signed-off-by: Sasha Levin commit 3bdd26582d026bdd86aa76f03989a1137b2490a0 Author: Lizhi Hou Date: Tue Sep 23 08:22:29 2025 -0700 accel/amdxdna: Enhance runtime power management [ Upstream commit 063db451832b8849faf1b0b8404b3a6a39995b29 ] Currently, pm_runtime_resume_and_get() is invoked in the driver's open callback, and pm_runtime_put_autosuspend() is called in the close callback. As a result, the device remains active whenever an application opens it, even if no I/O is performed, leading to unnecessary power consumption. Move the runtime PM calls to the AIE2 callbacks that actually interact with the hardware. The device will automatically suspend after 5 seconds of inactivity (no hardware accesses and no pending commands), and it will be resumed on the next hardware access. Reviewed-by: Karol Wachowski Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20250923152229.1303625-1-lizhi.hou@amd.com Stable-dep-of: 97f27573837e ("accel/amdxdna: Fix potential NULL pointer dereference in context cleanup") Signed-off-by: Sasha Levin commit 5a7d0e2810891c23533be53fa273cfbabec82eab Author: Hengyu Liang Date: Tue Sep 29 12:41:35 2026 -0400 ata: libata-scsi: do not lose CHECK CONDITION for failed ATAPI commands commit bc8ce2cea5f77c4bd1a5184705e300e83546c0c4 upstream. Since commit 2e1d2e65e773 ("ata: libata-scsi: terminate deferred commands on time out"), atapi_qc_complete() sets SAM_STAT_CHECK_CONDITION for a failed command only if cmd->result is zero, so that the DID_TIME_OUT or DID_REQUEUE host byte of a terminated command is preserved. However, cmd->result can also be non-zero for a regular failed ATAPI command completed through libata EH: ata_eh_analyze_tf() calls ata_eh_decide_disposition(), that is, scsi_check_sense(), on the sense data obtained with REQUEST SENSE, and scsi_check_sense() sets the SCSI midlayer internal byte of the result for some sense codes, e.g. SCSIML_STAT_TGT_FAILURE for ILLEGAL REQUEST with ASC 0x20 (INVALID COMMAND OPERATION CODE) or 0x24 (INVALID FIELD IN CDB), or SCSIML_STAT_MED_ERROR for MEDIUM ERROR with ASC 0x11 (UNRECOVERED READ ERROR). For such commands, atapi_qc_complete() keeps the result as is and the command completes with a GOOD status byte, even though it failed and valid sense data is available. As a result, passthrough users see these failed ATAPI commands as successful. For example, with the emulated IDE CD-ROM drive of QEMU and no medium loaded, a PLAY AUDIO MSF command issued with SG_IO completes with status 0x00 (and no DRIVER_SENSE) instead of 0x02 (CHECK CONDITION) with sense key ILLEGAL REQUEST, ASC/ASCQ 0x20/0x00, and the CDROM ioctls CDROMPLAYTRKIND, CDROMSUBCHNL, CDROMPAUSE, CDROMRESUME, CDROMPLAYMSF and CDROM_GET_MCN return 0 instead of -ENOMEDIUM or -EOPNOTSUPP. Fix this by setting the status byte to SAM_STAT_CHECK_CONDITION whenever the host byte is not set. Use set_status_byte() rather than overwriting the whole result, so that the SCSI midlayer internal byte set by scsi_check_sense() is preserved, as ata_scsi_qc_complete() already does for ATA commands. Fixes: 2e1d2e65e773 ("ata: libata-scsi: terminate deferred commands on time out") Cc: stable@vger.kernel.org Suggested-by: Niklas Cassel Signed-off-by: Hengyu Liang Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260929164135.266708-1-hengyul@cs.unc.edu Signed-off-by: Niklas Cassel [ sashal: Adjusted completion context to retain ata_qc_done() followed by return instead of ata_scsi_qc_done() and deferred scheduling. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e01c79761c7b3373e80094c5eadb21cb864fa8bc Author: Christian Brauner Date: Fri Oct 2 15:52:37 2026 +0200 namespace: handle mount locking for automounts correctly commit 33aadc7c72055fca93cb5a3691d836ebf8b31c9b upstream. If mounts are propagated across user namespaces, attach_recursive_mnt() locks every copy of the source mount to protect overmounts from vanishing and revealing the underlying files or directories. The user namespace is taken from the caller's mount namespaces since this is where the mounts end up. Except, that's not always true. Automounts may legitimately get popped in by tasks located in a different mount and user namespace during path lookup. Then check doesn't make sense at that point. The copy in the namespace of the parent - which may be the host's - is now locked and the host cannot change the flags of its own mounts anymore. Here's the reproducer: - host has debugfs mounted nosuid,nodev,noexec and shared - tracefs automount below it is not yet active - hand a child process a directory descriptor on that mount - child process enters auser and mount namespace - child process' namespace now holds a locked copy of the host's debugfs mount that receives propagation from it - child process stats "tracing/." through the descriptor - lookup runs on the host's mount so the automount lands below the host's mount - propagation puts a copy below the child's copy - both try to clear the flags on the mount they got, with a bind remount: host, on its own automount: MS_REMOUNT|MS_BIND = EPERM child, on the copy in its namespace: MS_REMOUNT|MS_BIND = 0 So the lock landed on the host's mount instead of the child's copy. Congrats. So we need to compare with the owner of the namespace the mount actually gets mounted on. For all regular cases that is the caller's mount namespace and so nothing changes. Detached trees in anonymous mount namespaces by be handed over via SCM_RIGHTS or inherited in other ways on purpose so the attaching task's mount namespace is authoritative, not the creator of the detached tree. Fixes: 132c94e31b8b ("vfs: Carefully propogate mounts across user namespaces") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-6-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 6b8dc3713a76346d212abab46cbfc8d7070f534c Author: Christian Brauner Date: Fri Oct 2 15:52:39 2026 +0200 namespace: never expire a locked mount commit f78ddcc872248c7aa1d7e904928441a0be4c6d5d upstream. Locked mounts are special. They protect the underlying files and directories from being revealed. do_umount() refuses to unmount locked mounts but shrink_submounts() doesn't. A shrinkable mount can become locked once the owner of a user namespace puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked property now moves to the mount at the bottom making it possible to unmount the top mount. So umount() of an unlocked ancestor now expires the bottom mount first and the covered directory is revealed: move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 the cover after the lock moved: umount2(x/hidden) = 0 the holder of the lock: umount2(x/hidden) = EINVAL the root of the copy, busy: umount2(x) = EBUSY reads x/hidden/secret: "covered-by-root" So leave a locked mount alone as it dies together with its parent. A plain umount() of an unlocked mount with a locked one below it is EBUSY from now on. It's the same for any other locked child. A lazy umount still takes the whole tree. mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree() leaves a mount on an expiry list alone and nothing else puts a locked one on such a list. Add an assert for this. Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users") Fixes: c62a4766937e ("move_mount: transfer MNT_LOCKED") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-8-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 494c57572d2d5bc2839553ed41aabe92ed0f587c 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 fa75dae156df15a1595aa2a19b5c0117de3e7d54 Author: Christian Brauner Date: Fri Oct 2 15:52:34 2026 +0200 fcntl: refuse F_SET_RW_HINT on an immutable inode commit b0d1022b9bdb1e98aa7fb3244fdd50a58c61766c upstream. An immutable inode is never written to so write hints are pointless. Refuse the hint on an immutable inode the way setattr(), fallocate() and etxattr() refuse their changes. Fixes: c75b1d9421f8 ("fs: add fcntl() interface for setting/getting write life time hints") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-3-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 5f97df8ca7fadf5b53954f50073445ba193902c0 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 d29cd99db3db74cf3447be74d25740981789d461 Author: Christian Brauner Date: Fri Oct 2 15:52:32 2026 +0200 namespace: unhash a dentry before detaching the mounts on it commit 528b383dc35d1e5caf64ddf5d35f983ae543b0d0 upstream. unlink(), rmdir() and rename() remove the entry from the filesystem, call detach_mounts() on the entry with the inode locked and then call d_delete() once the inode is unlocked. The thing is that between detach_mounts() and d_delete() the dentry is still hashed and positive. But after detach_mounts() nothing covers the dentry anymore. A lookup that finds this dentry in the dcache can uncover what the mounts hid. That's a problem when unlinking files or directories that are mountpoints in other mount namespaces. Everybody who had the underlying entry covered can race the detach_mount() call until d_delete() has run. The race window isn't all that small. It encompasses namespace_unlock() with a full synchronize_rcu_expedited() grace period and the inode_unlock() of the entry. In my experiments three walkers that kept trying read an overmounted file in 11938 of the 16140 unlinks that removed its mountpoint from a bind mount of the filesystem within a minute. Fun fact, d_invalidate() has the same ordering problem but gets it right. It unhashes the dentry first and detaches the mounts afterwards. Let's do the same in __detach_mounts(): - A lookup that hasn't found the dentry yet misses it in the dcache and waits for the directory lock that the caller holds until the name is gone for good. - A lockless lookup that found it already fails the mount_lock check while the dentry still counts as a mountpoint and the d_seq check once it doesn't, and retries. This fixes the lockless path. We still need to fix the reference count lookup in a follow-up patch. So d_drop() the dentry. The dentry stays positive and held but can't be found anymore. Then proceed with the detach and unlink. Reproducer: The reads were counted with the program below, three walkers for 60 s in a VM with 4 CPUs. The race window is stretched with the debug patch pasted here. fs.detach_race_walk_us sleeps in lookup_fast() once it found a mountpoint dentry and before its mounts are crossed. fs.detach_race_unlink_us sleeps in vfs_unlink() between detach_mounts() and d_delete(). // SPDX-License-Identifier: GPL-2.0 /* * unlink_covered: unlink a file that is a mountpoint in a detached copy of * its mount, against lookups 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-1-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 7e1c466011ba9e64d43075396badc03191bcee44 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 390ddcea2a8aca411b931a8e2863a80ccca8d2b3 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 e3aba6900483f64e6c9eb328150dd633b7d36c1c Author: Christian Brauner Date: Wed Sep 30 15:32:02 2026 +0200 namespace: check the mounts before reading their parents in pivot_root() commit 6b7c001eb5857fa09041f47673666060a2e5fc1c upstream. path_pivot_root() reads the parents of new_root and of the caller's root and checks whether they are shared before it checks that either mount is in the caller's mount namespace. Only namespace_sem is held. That's fine for a mount that is in the caller's mount namespace. But new_root can be a file descriptor to a mount that has been unmounted and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted nothing pins the parent for it. The final mntput() of the parent unhooks the children under mount_lock alone and frees the parent afterwards: pivot_root() close(fd), last ref on the parent ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath() __umount_mnt(new_mnt) cleanup_mnt() call_rcu() IS_MNT_SHARED(ex_parent) BUG: KASAN: slab-use-after-free in path_pivot_root+0xf1a/0x1840 Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157 path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190 The same goes for the caller's root via chroot(). Both outcomes of the check end in EINVAL so nothing but the read itself goes wrong. It's the same thing commit bb4609405752 ("statmount: read the parent of an unmounted mount under mount_lock") fixed for statmount(). Check that both mounts are in the caller's namespace before their parents are read. Every path returns EINVAL either way. Fixes: e0c9c0afd2fc ("mnt: Update detach_mounts to leave mounts connected") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-10-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 888363d74c3b5d32e2accf217add70f8b38e0e2b Author: Christian Brauner Date: Wed Sep 30 15:32:05 2026 +0200 namespace: remove the fsnotify marks of a mount namespace in process context commit 1a116222acdcc1bc1a8350727ae6f28907d44594 upstream. mnt_ns_release() drops the last passive reference of a mount namespace and removes its fanotify marks via fsnotify_mntns_delete(). That takes the mutex of every group with a mark on the namespace and the spinlock of the connector. Fine from process context. But mnt_ns_tree_remove() hands the reference the namespace was allocated with to call_rcu() and so the marks are removed from the RCU softirq: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:623 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/3 __mutex_lock+0x113/0x24b0 fsnotify_destroy_marks+0x11b/0x3d0 mnt_ns_release_rcu+0x57/0xa0 rcu_core+0x6b6/0x1e40 and lockdep complains about the connector lock being taken from softirq context. A fanotify group with a FAN_MARK_MNTNS mark on the mount namespace of another task is all that's needed. Root in a user namespace can do that for a mount namespace it owns. The task exits and the namespace is freed with the mark still on it. Remove the marks in free_mnt_ns() before the namespace is handed to RCU. That runs in process context once the last active reference is gone. A mark is added through a file descriptor to the namespace which holds an active reference so no mark can show up after that. Fixes: bf630c401641 ("vfs: add notifications for mount attach and detach") Cc: stable@vger.kernel.org # v6.15+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-13-be34c83956ae@kernel.org Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit b9c40553f6ceba50042281eef6f701e5fb719726 Author: Christian Brauner Date: Wed Sep 30 15:32:00 2026 +0200 namespace: look at the topmost mount for a mount namespace file commit 8714b44adac7b10506e1db3ef1710689751f0f10 upstream. attach_recursive_mnt() preallocates a mountpoint for the root of the topmost mount of the source so that a mount that already sits at the destination can be put on top of the source or on top of one of its propagated copies. The copies are made without CL_COPY_MNT_NS_FILE so their chain of overmounts is shorter than the source's. It ends below the first bind mount of a mount namespace file. So while the loop walks up the chain of the source it remembers the mountpoint of that mount in "shorter" and the existing mount is put there for the copies. But the loop ends at the topmost mount without ever looking at it. If the topmost mount is the only mount namespace file in the chain "shorter" stays NULL and mnt_change_mountpoint() attaches the existing mount of the copy below the root of the mount namespace file. That's a dentry of nsfs. No path walk in the copy's mount namespace ever gets there. The mount is gone until its parent goes and the copy that took its place can't be unmounted synchronously because it has a child: S bind mount of a file N bind mount of a mount namespace file on top of S A shared mount, B a slave of A, Q mounted on B/file move_mount(S, A/file) cat B/file -> the content of S instead of Q umount B/file -> EBUSY Look at every mount of the chain including the topmost one. Fixes: 96f5d2e05165 ("attach_recursive_mnt(): unify the mnt_change_mountpoint() logics") Cc: stable@vger.kernel.org # v6.17+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-8-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit a0ba48256f5dff6f75a45f8ce39fe57f21df1022 Author: Christian Brauner Date: Wed Sep 30 15:31:56 2026 +0200 namespace: check a recursive bind mount for mount namespace loops commit c640a01a78e42302879006ed7b7d5a9a943ba815 upstream. do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc//ns/ and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw Mount 152 is a mount of the mount namespace file of mount namespace 4026532293 inside mount namespace 4026532293. That namespace and every mount in it are leaked... All it takes is a process in an older mount namespace that stacks the file and repeating it leaks without limit: after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB do_move_mount() runs check_for_nsfs_mounts() over a detached tree for exactly that reason. Do the same for the copy before it is grafted. 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/20260930-work-mount-fixes-3-v1-4-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d73f04e92c1aab78d96ac6cadb234c8a3a373d22 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 acbe9e4418e2ef7bef1a12e62e0e7d6145a15190 Author: Christian Brauner Date: Wed Sep 30 15:31:53 2026 +0200 namespace: queue a mount only once for mount notifications commit bd2feb7796b6585938a4241e7b7c4148a6f7b762 upstream. mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40 This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace with a FAN_MARK_MNTNS mark does the rest and root in a user namespace can have both. Initialize to_notify in alloc_vfsmnt() and leave a mount alone that is queued already. mnt_notify() looks at the state the mount has when the list is drained so a single entry per mount is enough. The move event for a mount that is unmounted under the same hold is lost. That's fine. The detach is what matters. Fixes: bf630c401641 ("vfs: add notifications for mount attach and detach") Cc: stable@vger.kernel.org # v6.15+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-1-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 33b4344f690135fbcb74fdbe49cd899bca067560 Author: Christian Brauner Date: Sat Sep 26 15:44:28 2026 +0200 namespace: check the target before walking it in do_mount_setattr() commit 08f4288a37ef4b3d19b4a9599ec3048219cac828 upstream. When mount_setattr() changes the propagation type to MS_SHARED do_mount_setattr() takes namespace_sem and calls invent_group_ids() which walks the whole target tree with next_mnt() and allocates a peer group id for every mount that doesn't have one. Whether the caller may touch the target at all is only checked afterwards under mount_lock. If it may not, cleanup_group_ids() walks the tree a second time on the way out to free the ids again. A detached tree that a file descriptor keeps alive, a mount in another mount namespace or a mount below the root of an anonymous mount namespace does a bunch of allocation work that is completely useless because it will fail and revert right after. Do the right thing and check the target right after taking namespace_sem instead. A mount leaves its namespace only under namespace_sem so the mount stays stable. The check under mount_lock stays for the case where no propagation change is requested and namespace_sem isn't taken. Callers get the same EINVAL as before. Fixes: 2a1867219c7b ("fs: add mount_setattr()") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-5-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c44f5c30f0a97b95727c184a3254356bb6e7fd1f 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 b47b40c4f058418f9707454543179df240796aad 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 eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b Author: Christian Brauner Date: Sat Sep 26 15:44:26 2026 +0200 namespace: don't inherit MNT_UMOUNT in clone_mnt() commit e2c6d326216642011da318b9edfd5d57ebd5a56f upstream. MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source and only masks MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was lazily unmounted but is kept alive by a file descriptor can still be copied when its root is an nsfs or pidfs file because may_copy_tree() accepts those before checking whether the source is mounted at all: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y The mount on /tmp/y is attached to the caller's namespace with MNT_UMOUNT already set and every copy of it inherits the flag again. That causes a number of bugs: - Unlink its mountpoint from a mount namespace where it isn't one. __detach_mounts() takes it for a mount that was unmounted earlier, unhooks it from its parent and drops the reference the namespace holds on it. It stays in the namespace with one reference too few and as its own parent, so it can't be unmounted through the file descriptor anymore and the namespace never finds it again. When the namespace goes away it's leaked and points to a freed struct mnt_namespace that may_change_propagation() and anon_ns_root() read on the next propagation change or mount_setattr() through the file descriptor. - Make it shared and unmount a peer. trace_transfers() follows the flag from the peer into it and strips it from its peer group. - Let a propagated umount reach it. gather_candidates() marks it with T_UMOUNT_CANDIDATE but never puts it on the candidate list, so the mark is never cleared and every later propagated umount skips it. If it's the parent of a locked mount handle_locked() takes it as the cutoff and commits the locked child that should have stayed and disconnect_mount() leaves that child attached to it, unmounted under a mounted parent, which is what disconnect_mount() exists to prevent. When the namespace goes away umount_tree() visits the child a second time. And once __detach_mounts() has made it its own parent reparent() never finds the end of the chain of unmounted parents. A clone is a new mount that has never been unmounted. Add MNT_UMOUNT to MNT_INTERNAL_FLAGS so clone_mnt() never copies it. And warn when umount_tree() reaches a mount that already has it set. Fixes: 590ce4bcbfb4 ("mnt: Add MNT_UMOUNT flag") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-3-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5 Author: Christian Brauner Date: Sat Sep 26 15:44:24 2026 +0200 namespace: reset the old parent's ->overmount in mnt_change_mountpoint() commit 476ef286a7a5db8bda51325dc0c45887b4d99d9a upstream. __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed. do_lock_mount() follows ->overmount from the target path under mount_lock. With a file descriptor on such a mount as the target of a mount beneath topmost_overmount() walks into the freed mount and do_lock_mount() takes references on whatever it finds there. So reset ->overmount of the old parent in mnt_change_mountpoint() the same way __umount_mnt() does. A mount's ->overmount is then always a mount that is attached to it. Fixes: ffdc52fbbd58 ("prevent mount hash conflicts") Cc: stable@vger.kernel.org # v6.17+ Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-1-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit bf2c8dec26fb792876b5e9bde7030c45d8be3908 Author: Christian Brauner Date: Wed Sep 23 14:27:57 2026 +0200 fs: don't silently unmount busy mounts commit 6857e209015f95be7a8f19a9cd5dac345b9b9859 upstream. The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ended up adding covered mounts to both sides in one go. Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") and that started to unmount more than before: [1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted. So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn't look at copies of the victim that have two or more children nor a single child that is not the overmount. So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use. A container can run into this with its own mounts. The host shares a tree with the container and the host has a mount in that tree: mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a The container's /mnt is a slave copy of the host mount. The container now takes a detached copy of the tree and mounts that copy beneath its propagated copy of /mnt/a and keeps the file descriptor to the tree open: unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH) grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647 The now attached tree (777) is now mounted beneath the container's copy of /mnt/a. That's also where the host mount sits (as seen from the host mount namespace). So the propagated copy (776) of the host's mount is on top of its root and the copy of that (778) is inside it. Now the host runs: umount /mnt/a and it succeeds. The moved tree tree and the copy inside of it are gone from the container. Now only the propagated copy is left and it got reparented to where it was before: grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ... But the file descriptor still refers to the moved tree. So a synchronous umount detached a mount that is still in use. Teach propagate_mount_busy() the same checks that propagate_umount() does. It now checks for a single victim mount without children for which it can assume that MNT_LOCKED is cleared on every copy like propagate_umount() does. The copies form chains. IOW, when a copy itself receives propagation from the victim's parent then the mount at the same mountpoint inside that copy is a copy as well. Whether a mount receives propagation from the victim's can simply be checked by walking its masters. Walk each chain once from its top so we are sure that nested copies stay linear. Check every reference once of every copy that gets unmounted. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-5-f424cf8d3242@kernel.org Fixes: 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 9bd1181b36f2d1fb41e5d6b8697cc5e9247430d5 Author: Christian Brauner Date: Wed Sep 23 14:27:53 2026 +0200 mount: keep a copied mount unbindable commit 1ab8904ae61b076d1242e1f48537698c77074b5c upstream. It's groundhog day. MNT_UNBINDABLE used to be set in in mnt->mnt.mnt_flags and was not part of MNT_INTERNAL_FLAGS. clone_mnt() copied it with all the other flags to the new mount. This guaranteed that the copy of an unbindable mount became unbindable as well. Unbindable copies that ended up as shared lost the unbindable property. But then commit 406fea799925 ("mount: separate the flags accessed only under namespace_sem") moved MNT_UNBINDABLE from mnt->mnt.mnt_flags into mnt->mnt_t_flags as T_UNBINDABLE. clone_mnt() doesn't copy from mnt_t_flags and specifically doesn't copy T_UNBINDABLE. The only place a mount gets marked unbindable is in change_mnt_propagation() for MS_UNBINDABLE. This reintroduced an earlier bug we had already fixed. It resurfaces in copy_mnt_ns() which clones unbindable mounts via CL_COPY_UNBINDABLE. So since v6.17 a mount namespace created via clone(CLONE_NEWNS) or unshare(CLONE_NEWNS) contain private and bindable copies of every unbindable mount. The following snippet: mount --make-unbindable /mnt unshare -m --propagation unchanged mount --bind /mnt /tmp/x succeeds. This used to fail with EINVAL. This also applies to recursively binding a tree that contains an unbindable the mount. Such subtrees used to be pruned when they were moved onto a shared mount. And Documentation/filesystems/sharedsubtree.rst still says that the copy of an unbindable mount is unbindable. So once again let's fix this. Copy T_UNBINDABLE in clone_mnt(). Let set_mnt_shared() mask it off whenever a mount is made shared. This restores what the old MNT_INTERNAL_FLAGS mask did. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-1-f424cf8d3242@kernel.org Fixes: 406fea799925 ("mount: separate the flags accessed only under namespace_sem") Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c6307228af65a9a9a2bbcfad210eeebc21dce208 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 d9da2f7bbbffb121f1d42838665f79f88640443d Author: Jesse Zhang Date: Wed Sep 30 14:21:19 2026 +0800 drm/amdgpu/userq: return the memdup_user() error for the user MQD commit 76ceb6ed610cbf14341a9ba78c5c0b2199b9030a upstream. mes_userq_mqd_create() returns -ENOMEM when copying the user MQD fails, even though memdup_user() returns -EFAULT for a bad pointer or -EINTR when interrupted by a signal. Return PTR_ERR() instead. While at it drop the error messages. Neither case is a driver error and userspace shouldn't be able to spam the log with invalid IOCTL parameters. v2: drop the error messages (Christian) Fixes: 2c695d7c0720 ("drm/amdgpu: enable compute/gfx usermode queue") Fixes: 543b61453774 ("drm/amdgpu: enable SDMA usermode queues") Reviewed-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 49a443fcb829be9fc780f10850652ddea2fe81f0) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 112dbe2b10d6d088a6c599980dd960dcbfa55ff0 Author: Jesse Zhang Date: Wed Sep 30 14:21:19 2026 +0800 drm/amdgpu/userq: only accept doorbell BOs as queue doorbell commit 7f7c88dbf4d543f6703e53bdeed380e886733167 upstream. amdgpu_userq_get_doorbell_index() pins any BO passed as doorbell_handle into the doorbell domain. For a regular BO, TTM moves it with ttm_bo_move_null() and its contents are lost. Since an importer on the same device gets the exporter's GEM object, a client can do this to a buffer another client shared with it. Reject BOs that were not created in the doorbell domain. v2: drop the error message, use a local abo variable (Christian) Fixes: f09c1e6077ab ("drm/amdgpu: generate doorbell index for userqueue") Reviewed-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit f7497bbc19db4821c62b9d97b31c9086feb2d917) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 21aee7fc9310d2624551739f3afc2d8562658b4d 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 1a5c03198ae869537cc2c4a88a360cdf9f1e08ea 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 8d6f773d7479034a574ecc3b585bcd07d46b4824 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 3d4890b4ab04fe7c5da8fa656b0d9337d9f28f66 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 f009879ed99067e825512f7b759a174660edd703 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 3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684 Author: Thomas Hellström Date: Fri Oct 2 12:08:30 2026 +0200 drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin commit cf238c067eaae1cbfb00738e29219b9568d2313e upstream. xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which already runs on every unpin path (kernel, external, framebuffer, backup object) right before the true 1 -> 0 pin_count transition. Since list_del_init() only operates on the node itself, this removal is list-agnostic and safe to perform regardless of which list (external or kernel_bo_present) the bo happens to be linked on, or which code path is performing the final unpin. Drop the now-redundant explicit list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin(). v2: - New patch v3: - Rebased on changes to previous patch. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Maarten Lankhorst Cc: Rodrigo Vivi Cc: intel-xe@lists.freedesktop.org Cc: # v6.8+ Reviewed-by: Matthew Auld Reviewed-by: Himal Prasad Ghimiray Assisted-by: LLM Signed-off-by: Thomas Hellström Link: https://patch.msgid.link/20261002100830.12297-3-thomas.hellstrom@linux.intel.com (cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 993c952e6832ad0aa4be82e11f0760b1f532090a Author: Thomas Hellström Date: Fri Oct 2 12:08:29 2026 +0200 drm/xe: Fix shrinker accounting double-subtraction on nested external pins commit 83d5acca1f4f6132038ea88c72c5844f62e42d44 upstream. xe_bo_pin_external() and xe_bo_unpin_external() support nested pins, since the underlying ttm_bo_pin()/ttm_bo_unpin() maintain a pin_count refcount rather than a boolean. However, the shrinker accounting calls xe_ttm_tt_account_subtract() and xe_ttm_tt_account_add() are invoked unconditionally on every pin_external()/unpin_external() call, instead of only on the transition into and out of the pinned state. An external BO (dma-buf) can be pinned more than once while already pinned, for example when it has multiple attachments/importers, each independently calling xe_bo_pin_external(). Each such nested pin subtracts the BO's pages from the shrinker's accounting again, even though the BO's pages were already removed from consideration by the first pin. Symmetrically, each nested unpin adds them back again before the BO is actually unpinned. This desynchronizes the shrinker's page and object counts from reality, and since they are declared as signed long but interpreted as unsigned long in xe_shrinker_count(), the underflow can turn into an enormous shrinkable/purgeable page count, causing the shrinker to be invoked excessively under memory pressure. Guard the accounting calls with the same pin-count transition checks already used to guard the pinned_link list maintenance, so accounting is only updated on the outermost pin and the final unpin. While centralizing this logic into xe_bo_account_pin()/ xe_bo_account_unpin(), also close a second, related accounting gap affecting imported dma-bufs. For an imported bo's ttm_tt, xe's ttm_tt_populate hook (xe_ttm_tt_populate()) early-returns without calling xe_ttm_tt_account_add(), since TTM_TT_FLAG_EXTERNAL is set without TTM_TT_FLAG_EXTERNAL_MAPPABLE. However, TTM core's ttm_tt_populate() wrapper unconditionally marks the tt as populated on driver-hook success, so ttm_tt_is_populated() still reports true for it. xe_bo_account_pin()/xe_bo_account_unpin() trusted ttm_tt_is_populated() as a proxy for "these pages are accounted for by the shrinker", and would subtract/add pages for such a tt that were never added in the first place, again underflowing the shrinker's counts. This is reachable today via xe_bo_pin_external(), and would have become newly reachable via the fb-pin path once this patch routes __xe_pin_fb_vma() through xe_bo_pin_account() below, so fix it here rather than in a later patch, to avoid a commit in this series that introduces the regression before fixing it. Skip the accounting for imported bos, using the same EXTERNAL && !EXTERNAL_MAPPABLE test xe_ttm_tt_populate()/xe_ttm_tt_unpopulate() use to decide whether to act, via a new xe_ttm_bo_is_imported() helper (hoisted up from its only prior use site). v2: - Fix the critical issue caught by Sashiko AI review: the pin-count transition check introduced here was still bypassed by the fb-pin path (__xe_pin_fb_vma()/__xe_unpin_fb_vma()), which could leave a stale pinned_link entry and a permanent shrinker accounting leak when the fb-unpin performed the true last unpin. Addressed in a separate follow-up patch in this series rather than folded in here, since it is a distinct bug with its own Fixes: tag. - Drop the unneeded local "last_unpin" variable in xe_bo_unpin_external(), restoring the original inline bo->ttm.pin_count == 1 check; it was a no-op rename not used by any of the new accounting helpers, and was going to be deleted again by the follow-up patch anyway. v3: - Exclude imported dma-bufs from the pin/unpin shrinker accounting, fixing another underflow caught by Sashiko AI review. - Add a short comment on the backup-object pin site noting it's already populated/accounted at pin time, addressing (as a false-positive clarification, no code fix needed) a separate Medium-severity accounting-leak concern also caught by Sashiko AI review. Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: Thomas Hellström Cc: Matthew Brost Cc: Rodrigo Vivi Cc: intel-xe@lists.freedesktop.org Cc: # v6.15+ Reviewed-by: Matthew Auld Reviewed-by: Himal Prasad Ghimiray Assisted-by: LLM Signed-off-by: Thomas Hellström Link: https://patch.msgid.link/20261002100830.12297-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 6a117a2bb7ca657e3a19f83f4c06265d38dee06c) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 76e5ddd7d9822c8c3492e0f50ba8978e093069ad Author: Zack Rusin Date: Sun Aug 9 16:45:15 2026 -0400 drm/vmwgfx: validate pitch coming from userspace commit 21bc51cb89ced74d6645a138cc2f21184bc75094 upstream. Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping. Fixes: 2ac863719e51 ("vmwgfx: Snoop DMA transfers with non-covering sizes") Cc: stable@vger.kernel.org Reported-by: Youness HFA Signed-off-by: Zack Rusin Reviewed-by: Maaz Mombasawala Link: https://patch.msgid.link/20260809204515.211045-1-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit ea22f8a5d11a4090d0df01ce331c36b5828f5f72 Author: Wentao Liang Date: Wed Sep 16 15:40:15 2026 +0000 drm/vc4: Fix firmware reference leak in vc4_drm_bind() commit b816da5d5df1461446a0a5f3fe2b4948a659a790 upstream. The firmware reference obtained via rpi_firmware_get() is leaked when aperture_remove_all_conflicting_devices() fails, as the error label returns without putting it. This happens before the firmware is consumed and put further down in the function. Put the firmware reference before jumping to err. Fixes: c406ad5e4a85 ("drm/vc4: Notify the firmware when DRM is in charge") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260916154015.2056797-1-vulab@iscas.ac.cn Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit e61465d3e0292daebf4dbb34e0add635e2439569 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 f9b215b3e37a5047c406545de51bf8a2aeb4cd1c 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 0b4a0fb98b9ffeac36798bbd369c821605cae70f 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 152fb5083b9333a1cb8629572f9e0f276a404ba6 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 cd7bec509c180e3128159a6638b8c40f0225a33a 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 4e7b508c7c60dec7a86b7eb2a1b7e6d174afa457 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 a661f401f83b8462f2d424e0a1a72b7681e92ea2 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 4f46de658ce61968aef5ea7ae809d1c180330544 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 b108ea7ebba147465f4158d8133f0e8f013762ed Author: Aldo Ariel Panzardo Date: Sat Sep 26 18:21:45 2026 -0300 Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() commit 816fb1590a4c8cf8d05cd076057616be02e276f0 upstream. sco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a strong reference under hdev->lock: hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev); but the pointer is cleared from the other side without that lock. When the last sco_conn reference is dropped, sco_conn_free() ran conn->hcon->sco_data = NULL; with no hdev->lock held, so the RX path could read hcon->sco_data and call kref_get_unless_zero() on an sco_conn that was concurrently freed: BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730 kref_get_unless_zero() only guards against a zero refcount, not against the backing memory already being freed. Give hcon->sco_data an actual reference on the sco_conn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from sco_conn_del(), which runs under hdev->lock (its callers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in sco_recv_scodata() also takes hdev->lock, so the store and the read are now serialised: the RX path either observes NULL or a reference that is guaranteed to stay valid until it drops its own. sco_conn_add() no longer hands its kref_init() reference to the caller as the connection's only reference; that initial reference is the one owned by hcon->sco_data, and callers get their own via sco_conn_hold(). Because the sco_conn can now outlive the socket (the association keeps it alive until the link goes down), the hci_conn can no longer be dropped from sco_conn_free() without regressing socket close: closing a connected SCO socket must still tear the link down. Move hci_conn ownership to the socket instead: __sco_chan_add() takes an hci_conn reference and it is released from sco_chan_del() and sco_sock_destruct(), exactly once. The sco_conn no longer owns an hci_conn reference, so sco_conn_add() stops consuming one and sco_connect() drops the hci_connect_sco() reference on every path; sco_connect_cfm() no longer needs its hci_conn_hold() dance. Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn") Cc: stable@vger.kernel.org Suggested-by: Pauli Virtanen Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit ec227cddd13cd7ac9077d263a73473ac370a055d 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 c6489a3a0ac8c07f64cb5b44f005bc518f1048ac 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 90b744066ca520d1a6a505a11ade9c9a5f48accf 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 7db33b36213a3a1a40940c009ddac30670b55922 Author: Chengfeng Ye Date: Mon Oct 5 00:26:12 2026 +0800 Bluetooth: hci_sync: Fix command skb lifetime during scan setup commit 9af12272061d206af8bc3e40215cb694421ab73a upstream. During PA sync scan setup, hci_le_set_ext_scan_param_sync() gets the address used for the PA_LINK lookup from hci_sent_cmd_data(). The returned pointer borrows storage from sent_cmd or req_skb, without holding a reference to either skb. The scan worker runs on req_workqueue while hci_cmd_work() runs on the separate device workqueue. After the scan worker loads sent_cmd, the command worker can free and replace it before hci_sent_cmd_data() dereferences the skb. The command payload can also be freed between returning from the helper and comparing the address. The connection lookup's RCU critical section does not protect the command skb. KASAN reported: BUG: KASAN: slab-use-after-free in hci_sent_cmd_data+0x27c/0x2f0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_sent_cmd_data+0x27c/0x2f0 hci_le_set_scan_param_sync+0x43a/0x850 hci_passive_scan_sync+0xb09/0x1460 hci_update_passive_scan_sync+0x47c/0x6e0 hci_le_pa_create_sync+0x200/0xa70 hci_cmd_sync_work+0x13c/0x290 Allocated by task 95: skb_clone+0x13f/0x340 hci_cmd_work+0x2a9/0x7e0 Freed by task 95: kmem_cache_free+0xba/0x3a0 hci_cmd_work+0x29c/0x7e0 Use hdev->lock to serialize the address snapshot with sent_cmd replacement. Protect req_skb replacement and completion cleanup with the same lock because the helper falls back to that skb. Copy the address before releasing the lock and use the copy for the existing RCU-protected connection lookup. Release the mutex before sending or waiting for commands, preserving the lookup and completion ordering. Fixes: 22cbf4f84c00 ("Bluetooth: hci_sync: Use QoS to determine which PHY to scan") 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 c3d2799877906d0c8392d96e14216cd82b020330 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 c9c20d334cd5e05184b62b6124678ed9cab75029 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 71beae6f2e8bc8673b4f6ecd2034044e508559a4 Author: Zongmin Zhou Date: Mon Oct 5 19:02:37 2026 -0600 riscv: hwprobe: use _BITULL() rather than BIT() in MIPS vendor uapi header commit edba6017c19f97ecc718fad6b50e0908392247ac upstream. BIT() is a kernel-internal macro that is not available to userspace, but the MIPS vendor extension uapi header uses it without defining or including it. Any userspace program that includes this header and uses RISCV_HWPROBE_VENDOR_EXT_XMIPSEXECTL fails to build. Use _BITULL(0) from linux/const.h instead, which keeps the value at 1, so there is no ABI change. Fixes: bb4b0f8a1bcb ("riscv: hwprobe: Add MIPS vendor extension probing") Cc: stable@vger.kernel.org Signed-off-by: Zongmin Zhou Reviewed-by: Jesse Taube Link: https://patch.msgid.link/20260918073650.42586-1-min_halo@163.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d Author: Ziyi Guo Date: Tue Oct 6 14:02:00 2026 +0000 riscv: futex: untag the user pointer before the atomic access commit 405290be962b32eec842776fbe3bdf81f15b1676 upstream. access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the "+m" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address. Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle. get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated. Fixes: 2e1743085887 ("riscv: Add support for the tagged address ABI") Reviewed-by: Samuel Holland Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20261006140200.877263-1-guoziyi114@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit b86e88a3dc6e1fb2ccc7efbb07ed883b9e2236b1 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 fa465a7819ecbe5801b78c088d3cadaf2664b8ca Author: Zongmin Zhou Date: Thu Sep 17 15:48:43 2026 +0800 riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE commit 298510bbc7c3017c0faf481c6ea66f1065b657b4 upstream. errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports "Not affected" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied. Fixes: 4bf97069239b ("riscv: Add ghostwrite vulnerability") Signed-off-by: Zongmin Zhou Link: https://patch.msgid.link/20260917074843.52716-1-min_halo@163.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 7d1367a53137e379498eb8791295e58854378636 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 8bfcbd5022818b37cad44fab9b8e2f3a642cbf54 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 ce2eee635fd3e5a87f009331140b6fc188ae30e0 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 1072890e6c1af790174982b780fde29be6067579 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 5874c0e2bd0302d5381a5c3704b0f1e76d2a104b 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 28606d4d4dbe822b74e87e7c7a252ca96945d9cb 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 f6fbe9c6b39968a7696b9badef4bc29331a6376a 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 199a62d70314d21f06a9a6faaa3ef54d0404910c 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 681adbc9c7a820279582a295e183fa6a1d1b4ec4 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 55f12552b00a34ca7ab5cf2d2b5ed02f8f06a965 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 558a189ca357d48172907890072fde370b057206 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 961563117626f4681623077ec0cfd86f86da0d49 Author: Weiming Shi Date: Fri Oct 2 02:23:26 2026 +0800 net: team: free skb when broadcast has no txable port commit 489114c9ecae44e523361a4b3e610ee5ebd9189c upstream. bc_transmit() sends the original skb through the last txable port. When no port is txable, it returns false without consuming the skb, but team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the skb and its socket write-memory charge. A TX-enabled, link-down port keeps the broadcast transmit op installed. Carrier can stay up through a second link-up, TX-disabled port or be forced on by userspace. Free the original skb on the no-port path while leaving the existing drop accounting intact. Discovered by Sashiko during review of previous commit. Cc: stable@vger.kernel.org Fixes: 5fc889911a99 ("team: add broadcast mode") Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20261001182326.572045-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0c0568c9d35c47dc8e3ef6705d4c35a02bd88c4e Author: Weiming Shi Date: Fri Oct 2 02:23:25 2026 +0800 net: team: stop reusing skb after queue override commit b7454f1940c5e6d92e753853c476a769e452f30a upstream. A nonzero dev_queue_xmit() result does not return ownership of the skb. When an override port's qdisc drops it, the queue override helper used to try another port or the mode transmit op with the freed skb. Return the handoff decision separately from transmit success. Select only the first override port under RCU and stop after handing it the skb, regardless of the lower transmit result. Keep the existing success and drop accounting. BUG: KASAN: slab-use-after-free in sk_skb_reason_drop Write of size 4 by task poc/5040 sk_skb_reason_drop (net/core/skbuff.c:1240) dev_kfree_skb_any_reason (net/core/dev.c:3470) ab_transmit (drivers/net/team/team_mode_activebackup.c:49) team_xmit (drivers/net/team/team_core.c:1849) __dev_direct_xmit (net/core/dev.c:4934) Freed by task 5040: __tcf_kfree_skb_list (net/sched/sch_generic.c:43) __dev_queue_xmit (net/core/dev.c:4831) team_xmit (drivers/net/team/team_core.c:1846) Kernel panic - not syncing: KASAN: panic_on_warn set ... Cc: stable@vger.kernel.org Fixes: 8ff5105a2b9d ("team: add support for queue override by setting queue_id for port") Reported-by: Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20261001182326.572045-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5b144f83f2179437027bbaf9d75e58df2d73af1a 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 cc7cc5955d22ea90555f09a680d4bf56d4a0c24a 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 5551399751e2c9f31e4f3428040985a07e79d9c2 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 d7fea7141036f3fe3b0d19c03b78ea94e29a149e 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 d109141ba14652146089ef78b32d5e4d5285ebad 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 6a1833f0d7dc037c8e876b9178ba69d5d107c086 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 3efe0e0944157fdd2072b4dc7eb0491a317ed272 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 3a1caa886d41d9bcc9a402906336eda34a90d323 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 46e75703ca3f00fb8c935b3ce35b90836e34e8af 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 9ac3fd9dc917d0adb3b3837fa43cd2ceede38bb3 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 8668f432a9bf7b6241bd9a89f9960e7692fbd69b 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 e3bf232c913b7e0103d323f15e6342d37cb1b357 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 c86f80cd246c09e6cea3049d131f9b0c6761f89f 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 4f0ee735dc68e3e6c4dd9a666d7f7047163c4165 Author: Ben Cressey Date: Tue Sep 15 00:37:35 2026 +0000 dm-integrity: fix buffer overflow in inline mode with large tag size commit 764b683a6180fd72c931c13fea98d383506a3475 upstream. In inline mode, dm_integrity_check and dm_integrity_inline_recheck compute the checksum of each block into an on-stack buffer of HASH_MAX_DIGESTSIZE bytes. integrity_sector_checksum pads its result with zeroes up to the tag size, so if the tag size is larger than HASH_MAX_DIGESTSIZE, the padding runs past the end of the buffer. With CONFIG_STACKPROTECTOR the kernel panics in dm_integrity_check on the first read. Enlarge both buffers to hold MAX_TAG_SIZE bytes, as commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size") did for integrity_metadata. Note that this is not a security bug because the buffer overflow can only be triggered by root. Fixes: fb0987682c62 ("dm-integrity: introduce the Inline mode") 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 a1a875614dae43b43d311bb9e7a7a70eed78efe6 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 7a25ca170c12a9328f6fcf4410713beb516b01c0 Author: Mikhail Gavrilov Date: Fri Sep 25 10:06:47 2026 +0500 mm: don't schedule deferred kernel page table freeing while booting commit 2fb552b0bee70c24c092720028ab4620f5eb2646 upstream. Booting with a boot-time function tracer and a filter, for example ftrace=function ftrace_filter=pud_free_pmd_page panics on 7.3-rc4 as soon as the tracer starts: [ 23.531178] Starting tracer 'function' [ 23.675800] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN NOPTI [ 23.819917] KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] [ 23.964025] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.3.0-rc4-fe2ec83746e5-with-fixes-v2+ #195 PREEMPT(undef) [ 24.252248] RIP: 0010:__queue_work+0xab/0xf00 [ 25.981629] Call Trace: [ 26.125727] [ 26.413912] ? pagetable_free_kernel+0x20/0x120 [ 26.990283] queue_work_on+0x97/0xf0 [ 27.134382] __cpa_collapse_large_pages+0x501/0x6f0 [ 27.566662] cpa_flush+0x394/0x620 [ 27.998953] change_page_attr_set_clr+0x321/0x4a0 [ 29.151729] set_memory_rox+0xa2/0xf0 [ 29.584018] create_trampoline+0x431/0x6f0 ... [ 44.343347] Kernel panic - not syncing: Attempted to kill the idle task! The boot-time tracer is started from early_trace_init(), which runs before workqueue_init_early(). Making its trampoline read-only splits a large page, and CPA collapses it again right away. The split table has been a kernel page table since commit 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables"), so the collapse frees it through pagetable_free_kernel(), which queues work on system_percpu_wq - still NULL at that point. That commit is correct in itself; it only lets CPA reach pagetable_free_kernel() before the workqueue that function relies on exists. Keep putting the table on the list, but don't schedule the work while the system is still booting. A core_initcall schedules it once to free whatever was queued by then. Link: https://lore.kernel.org/20260925050647.86913-1-mikhail.v.gavrilov@gmail.com Link: https://lore.kernel.org/20260924064321.23787-1-mikhail.v.gavrilov@gmail.com Fixes: 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables") Signed-off-by: Mikhail Gavrilov Signed-off-by: Andrew Morton Suggested-by: David Hildenbrand (Arm) Suggested-by: Lorenzo Stoakes (ARM) Reviewed-by: Andrew Morton Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Jose A. Perez de Azpillaga Tested-by: Jose A. Perez de Azpillaga Cc: Dave Hansen Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Vishal Moola (Oracle) Cc: Ingo Molnar Cc: Lu Baolu Cc: Jason Gunthorpe Cc: Steven Rostedt Cc: Signed-off-by: Greg Kroah-Hartman commit d7e811c3a49cd5cff529c157df886719e09370ec 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 f2795c50144d528dabc2cf2fd53c0f0c63a823a1 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 11516a0c402a6c1fa52254aa70d8d65fb921e59e 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 955b1f75c400180b7f8d42794aa7b7cc32e54c0a 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 beb05f484a1e4a5a66e3678e4b7f3147f651c080 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 ca8a6285b11d01e5a279b1aa7fb55b1a02ecebb1 Author: Xuanqiang Luo Date: Mon Sep 28 16:04:23 2026 -0700 ice: fix use-after-free in dynamic port cleanup commit 1402fc67d2f4e2e1fc7bf8ee0825b8ad994557ff upstream. ice_dealloc_dynamic_port() uses dyn_port->vsi->idx to erase the dynamic port from pf->dyn_ports. However, it frees the VSI before reading the index for the erase, resulting in a use-after-free. Follow the reverse of the allocation order in ice_alloc_dynamic_port() by erasing the xarray entry before freeing the VSI. Fixes: eda69d654c7e ("ice: add basic devlink subfunctions support") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Marcin Szycik Reviewed-by: Aleksandr Loktionov Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260928230429.495442-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bb8f6b89587d0770dadcf584f496aa31535d81c7 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 a065bd31ec462f6f9c267026b708dd020f122723 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 06656aaa7e43ae62b673c2244d27099b8b94a70d Author: Joshua Washington Date: Wed Sep 30 14:47:34 2026 -0700 gve: fix XSK buffer leak on error descriptor commit 9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e upstream. When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM. Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy") Cc: stable@vger.kernel.org Reviewed-by: Jordan Rhee Reviewed-by: Tim Hostetler Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-3-joshwash@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 506f9de069d07a72b9887ce3edd2fdf32f4953aa Author: Joshua Washington Date: Wed Sep 30 14:47:33 2026 -0700 gve: fix XSK buffer leak when rings are stopped commit 73670ddb91a4d22e1deb3efd962242de1ec48e90 upstream. GVE does not free XSK buffers when resetting ring state as a part of stopping queues. This causes all XSK buffers which are posted to the NIC to be leaked. Free XSK buffers attached to an allocated buf_state when stopping rings. This issue was hit in production. Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy") Cc: stable@vger.kernel.org Reviewed-by: Tim Hostetler Reviewed-by: Jordan Rhee Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-2-joshwash@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 42935a61001927aa01db10b53b420efd37eaa99b Author: Joshua Washington Date: Wed Sep 30 14:47:35 2026 -0700 gve: fix napi_disable deadlock when attempting to disable XSK pools commit 0cb6939a4dfefa822007b7a71986e06bc4f61f54 upstream. When disabling XSK pools, GVE calls the unlocked versions of napi_disable and napi_enable. However, the netdev lock has already been acquired before ndo_bpf is called because GVE supports queue management ops. Calling the unlocked versions of napi_disable/enable results in a deadlock when attempting to disable XSK pools, as the thread attempts to re-acquire a lock it already holds. Update the NAPI calls to use the locked versions. This issue was found in production. Fixes: 606048cbd834 ("net: designate XSK pool pointers in queues as "ops protected"") Cc: stable@vger.kernel.org Reviewed-by: Harshitha Ramamurthy Reviewed-by: Jordan Rhee Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-4-joshwash@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a027e0d7765d1531ee39e4dae81951b04f32ba7b 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 76390ac0bca7e5058b7482eb4d951c3bda5df812 Author: Fan Wu Date: Tue Sep 29 09:36:46 2026 +0000 gpio: mpsse: fix race when arming the IRQ poll worker commit 7efa1a1953cd6b20b23a3524d5b4b81789c6ef25 upstream. gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv->workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free. Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running. A worker armed after the disconnect walk would still be missed, so also set a new priv->dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core's raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared. This issue was found by an in-house static analysis tool. Fixes: 179ef1127d7a ("gpio: mpsse: ensure worker is torn down") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260929093646.18419-1-fanwu01@zju.edu.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 1eb70d10bbb8ab5ba1b67aa8b3d42ef13a1e33da 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 2d79ddc9a0cc0f611687a991e687eeb29f98987b 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 5509d498e1b9edafebd5a60ba3cb9ecfda23dc2b 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 5a41bcc5057dc2160e5f8a553a8880240f203ed7 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 215c29f7f46068220fc1c002be18566c06e6fc14 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 1428c5f1d346a2e1ac9156713975a72246957009 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 0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e 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 1c7463ac0e99cc91c4eecc1b69a740ef1a619932 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 3d555c31b0d2777af3f38c678f982e37886fa9b3 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 d2b5f637b9b67a79a50d42614d10653c13b4e449 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 65cb86860a80ffc6af897d53f5bd4b1733bca0ec 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 086944c1c2cbb683543bc3ff08637847b03c8009 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 b12a25fb2b9d5dac80e419d695450cc17a51fdfd 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 4d64a3d6e96aa78619c9c29ffde309794974588a 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 38da24fd5c9d077d19b9afe40a93d7917bd3dacc 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 d730b466496ce25accae522a8429116512c3b0f4 Author: Lu Huang Date: Wed Sep 30 16:54:35 2026 +0800 wifi: mt76: mt7996: fix uninitialized buf read in mt7996_variant_fem_init() commit 52f6a065e0810c739a5dabd33a58047f08100f50 upstream. When the eFuse block covering MT7976C_EFUSE_OFFSET is invalid, mt7996_mcu_get_eeprom() returns -EINVAL without writing buf, but mt7996_variant_fem_init() tolerates -EINVAL and keeps running, so buf[idx] == 0xc reads uninitialized stack memory. A stale 0x0c byte misclassifies a 0x7976 aDie as 7976C, selects MT7996_FEM_INT and the wrong default EEPROM, overriding valid calibration data. Only consult the eFuse byte when the read succeeded; with an invalid eFuse, fall back to the three explicit aDie version checks. Fixes: e8cb33ad546a ("wifi: mt76: mt7996: add support for more variants") Cc: stable@vger.kernel.org Signed-off-by: Lu Huang Link: https://patch.msgid.link/20260930085435.1424493-1-huanglu@kylinos.cn Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit dd117d17e8aa2e89f857fb708e5b770709fb81cb Author: Cristian Papa Date: Thu Sep 3 22:07:02 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 Signed-off-by: Greg Kroah-Hartman commit eef16a74ff8ed2a838d6bb862bb2c7783fce7466 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 38bad3930b1185dd6c98db3dd342ddc123c6f3ef 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 6139c710d8bee4c2a69732da18caace957940ae0 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 5680b6fb3054677d4ee65d3baba24b649f1b430e 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 2200fe1d6148b78e1b8f00f4b2bd47760015077f 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 8d88d3221204fbb1b6dc2c0f2f2181fe49126639 Author: Waiman Long Date: Fri Oct 2 12:54:38 2026 -0400 cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus() commit 23b1ab15ca91f2cffaf149d9bb0fafeb700c7db2 upstream. With commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 ("cgroup/cpuset: Always use cpu_active_mask") updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit. In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset. Fix this by adding back the NULL cs check to avoid this problem. Fixes: 7a0aabd9ce69 ("cgroup/cpuset: Always use cpu_active_mask") Cc: stable@vger.kernel.org # v6.16+ Reported-by: Farhad Alemi Link: https://lore.kernel.org/lkml/CA+0ovChh3VjsKN1g+ZGjwwY2fGTpP7uD+aCCByLj5Qbymw=bfQ@mail.gmail.com Signed-off-by: Waiman Long Tested-by: Farhad Alemi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 12ba7d8b9cd45a2c6aa8f37c3f4b8a50422fb549 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 a768b88cd157b56c259dfb13a6bb7d98532ecb0d 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 13bbcfe755d4607f0a22481cf361bac8c3fcb133 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 1ea7241101753399c6e6d96026b31d65e40f6095 Author: Mohamed Yassine Jebabli Date: Thu Oct 1 12:24:42 2026 +0200 ALSA: hda/tas2781: Accept V1 calibration data without CRC commit 408249089c48df1a4d23f60b831be3f3c311e6d1 upstream. Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H, SSID 17aa:38cd) store valid V1 calibration data in the CALI_DATA EFI variable but leave the TimeStamp and CRC fields zeroed. The driver rejects such data, so the amplifiers always run with default parameters on these machines. The rejection was silent until commit 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") turned it into "V1 CRC error". The stored values are consistent (R0 = 3.82/3.83 ohm, 1/R0 matching within 1e-4), so accept V1 data when both TimeStamp and CRC are zero and the first device entry is non-zero, and emit a warning. Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Yassine Jebabli Link: https://patch.msgid.link/20261001-tas2781-v1-nocrc-v1-1-ff0c1032ce76@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f7dc71c1ce885f5d9f128037ebc75d9c0356e060 Author: Harin Lee Date: Thu Oct 1 23:45:01 2026 +0900 ALSA: ctxfi: Fix memory leakage when clearing DAO input mappers commit 593d46fc6af9a0178a46e77d6d24b20d2314165f upstream. Commit e576e7843c0d ("ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions") centralized the DAO input mapper clearing logic in dao_clear_input(), but omitted the kfree() calls. It removes the mapper entries from the list and sets their pointers to NULL without freeing the allocated array. This leaks memory each time dao_clear_input() is called. Store the base pointer of the allocation before clearing the mapper entries and free the array after removing entries from the list. Fixes: e576e7843c0d ("ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions") Cc: stable@vger.kernel.org Signed-off-by: Harin Lee Link: https://patch.msgid.link/20261001144501.3050667-2-me@harin.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0b0278e760d7b5012dbbc3637e39ac885f8602a9 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 2e4f80c0231197114d4466d04320d9e48ee73358 Author: Bihaan Sen Date: Fri Sep 25 17:14:38 2026 +0530 Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox commit 41363c27b8509bd4efcba244803edac9ba25d1b5 upstream. The 8BitDo Pro 2 Wired Controller for Xbox is already matched by the vendor-wide XPAD_XBOXONE_VENDOR(0x2dc8) entry, but a later hardware revision reports product ID 0x201e, which has no entry in the xpad_device table. The device therefore binds and functions but is exposed to userspace as "Generic X-Box pad". Add the VID/PID pair so the controller is named correctly, and set MAP_SHARE_BUTTON to expose the share button as KEY_RECORD. Signed-off-by: Bihaan Sen Link: https://patch.msgid.link/20260925114459.110253-1-stevewholikesthings@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d738e51bf2c21921df351f536147178ae3cbd38b 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 4ac7d92a4698e34e614c254359665b9de1f65283 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 7dfa7ca97f3ac46353edd4cc44f7733758e4535b 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 c1f48d1c2d5e9efd904dbbc2f2b3d41543e55c49 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 21cba134c30c17ae55f468b5809336437df5d7e6 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 c6d670ac656badfd0e15355e07a13a6bdf3b69fd 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 71cbad138969edecef01b28dff87d91b56db538d Author: Alice Ryhl Date: Thu Sep 3 11:36:03 2026 +0000 rust_binder: reschedule node refcount update on thread exit commit 2a74ccd1bcc170e66525f34e9de8652b57e2cf3d upstream. When a thread exits via BINDER_THREAD_EXIT, its pending work items are cancelled. If a thread exits while holding a pending node refcount increment (e.g. pushed as deferred work to that thread), the refcount increment was previously dropped because Node::cancel() and NodeWrapper::cancel() were no-ops. Dropping the refcount update leaves the node's delivery state and count state desynchronized, and userspace will not receive the notification, which can cause the node to never be freed from the process's nodes tree when all external references are dropped. Fix this by implementing DeliverToRead::cancel() for Node and NodeWrapper to move the pending refcount update to the process's work queue on thread exit so another thread can deliver it to userspace. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260903-binder-thread-exit-node-v1-1-be09ff14f6a4@google.com [ Dropped first argument in calls to `push_work()` to adjust to the existing form without mainline commit dbb17c9ea756 ("rust_binder: move (e)poll wait queue to Process"). - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit f3e835af6226f1dd12160cbd696081e9b6155de0 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 fa1bceba169b1c2e75fa394e1f8450577be4a761 Author: Ido Schimmel Date: Fri Aug 28 22:23:41 2026 +0300 ipv6: Fix redirect exception creation for UDP/RAW sockets [ Upstream commit cd51b74bdd0b75aedf255dc67306a16dd057f7ee ] When an ICMP Redirect Message is matched to a socket, both IPv4 and IPv6 verify that the source IP of the ICMP packet is the current gateway for the quoted packet. Both also pass the socket's bound device as the expected nexthop device. The difference is that IPv4 treats "oif=0" as "any", whereas IPv6 always requires an exact match (see ip6_redirect_nh_match()), since the gateway address is usually a link-local address. Therefore, when an IPv6 UDP/RAW socket is not bound to a device, the above verification fails and an exception is not created. This also happens when the socket is bound to a VRF, as l3mdev_update_flow() resets the oif to 0. Fix this by passing the ifindex of the ingress device as the expected nexthop device. This is consistent with the existing callers of ip6_redirect(). Note that for ICMPv6 Redirect Message packets the VRF driver does not reset skb->dev to the VRF device, so skb->dev is correct, even when it is a VRF port. Fixes: b55b76b22144 ("ipv6:introduce function to find route for redirect") Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260828192344.2596928-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 61a32face36f739ac630d19503e6a84a9080fba5 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 af98611ad109efcbfe3ba68eb10124ebc3257224 Author: Daniel Golle Date: Fri Oct 9 22:08:08 2026 +0300 net: dsa: mt7530: fix .get_stats64 sleeping in atomic context commit 07d99587396024932e02474c3a5bede71d108454 upstream. The .get_stats64 callback runs in atomic context, but on MDIO-connected switches every register read acquires the MDIO bus mutex, which can sleep: [ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609 [ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep [ 12.663377] preempt_count: 0, expected: 0 [ 12.667410] RCU nest depth: 1, expected: 0 [ 12.671511] INFO: lockdep is turned off. [ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT [ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 12.675456] Hardware name: Bananapi BPI-R64 (DT) [ 12.675459] Call trace: [ 12.675462] show_stack+0x14/0x1c (C) [ 12.675477] dump_stack_lvl+0x68/0x8c [ 12.675487] dump_stack+0x14/0x1c [ 12.675495] __might_resched+0x14c/0x220 [ 12.675504] __might_sleep+0x44/0x80 [ 12.675511] __mutex_lock+0x50/0xb10 [ 12.675523] mutex_lock_nested+0x20/0x30 [ 12.675532] mt7530_get_stats64+0x40/0x2ac [ 12.675542] dsa_user_get_stats64+0x2c/0x40 [ 12.675553] dev_get_stats+0x44/0x1e0 [ 12.675564] dev_seq_printf_stats+0x24/0xe0 [ 12.675575] dev_seq_show+0x14/0x3c [ 12.675583] seq_read_iter+0x37c/0x480 [ 12.675595] seq_read+0xd0/0xec [ 12.675605] proc_reg_read+0x94/0xe4 [ 12.675615] vfs_read+0x98/0x29c [ 12.675625] ksys_read+0x54/0xdc [ 12.675633] __arm64_sys_read+0x18/0x20 [ 12.675642] invoke_syscall.constprop.0+0x54/0xec [ 12.675653] do_el0_svc+0x3c/0xb4 [ 12.675662] el0_svc+0x38/0x200 [ 12.675670] el0t_64_sync_handler+0x98/0xdc [ 12.675679] el0t_64_sync+0x158/0x15c For MDIO-connected switches, poll MIB counters asynchronously using a delayed workqueue every second and let .get_stats64 return the cached values under a spinlock. A mod_delayed_work() call on each read triggers an immediate refresh so counters stay responsive when queried more frequently. MMIO-connected switches (MT7988, EN7581, AN7583) are not affected because their regmap does not sleep, so they continue to read MIB counters directly in .get_stats64. Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64") Signed-off-by: Daniel Golle Acked-by: Chester A. Unal Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/6940b913da2c29156f0feff74b678d3c526ee84c.1777719253.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski [ Aleksei: context adjusted, 6.18 still exports mt7530_switch_ops ] Signed-off-by: Aleksei Sviridkin Signed-off-by: Sasha Levin commit 4d8ed219b192126d7845414e2a5fb2ad8d4717c9 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 b2cf17d39dd2cc226033fbb669977b6951a6fc11 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 [ Sasha: applied Chao's 6.12.y backport to 6.18.y; gc.c context uses is_cursec(), which 6.18 has ] Signed-off-by: Sasha Levin commit 3f63f071bf82b44b9847b28ee9f3d98d973d327e Author: Eva Crystal <0xiviel@gmail.com> Date: Fri Oct 9 16:26:14 2026 +1300 accel/amdxdna: Bound the sync_bo flush range to the BO size [ Upstream commit dbc8fd7a03cbc0704e8e558a448015f620547a02 ] amdxdna_drm_sync_bo_ioctl() passes the caller's offset and size to drm_clflush_virt_range() on the BO's kernel mapping without checking either against the BO size. The ioctl has no permission flags: any process that can open the accel node controls the offset. Any BO with a kernel mapping reaches that call: AMDXDNA_BO_DEV_HEAP, AMDXDNA_BO_DEV and AMDXDNA_BO_CMD. A DEV_HEAP is vmapped, so an offset equal to its size lands the flush on the vmap guard page. Measured on 6.18.55 on an AMD Ryzen AI 9 365 NPU, firmware 1.0.0.63, as a non-root user with access to the accel node: unpatched, an offset equal to the 64 MiB DEV_HEAP size oopses in drm_clflush_virt_range() under amdxdna_drm_sync_bo_ioctl(), 2 of 2 runs; patched, the same call returns -EINVAL, 2 of 2, and an in-bounds sync returns 0, 2 of 2. DEV_HEAP is the type tested; DEV and CMD are by code reading. Upstream bounds the range in amdxdna_flush_bo(), added by commit dbc8fd7a03cb ("accel/amdxdna: Add expandable device heap support"). This applies only that check: an offset at or past the BO's end, or an overflowing offset plus size, returns -EINVAL. Deviations from upstream: that commit adds a feature and is too large for stable as a whole. It calls drm_WARN() when the check rejects a BO whose type is not AMDXDNA_BO_DEV, which userspace can trigger; this fix does not. Upstream bounds AMDXDNA_BO_DEV by the heap chunks it spans and flushes only the overlap, reporting no error for an offset past the end; 6.18 has one heap per client, so this fix uses the BO's own abo->mem.size and rejects such an offset instead. As in upstream, a size past the BO's end is clamped, not rejected. Built from v6.18.55 with the test system's distro-derived config, DRM_ACCEL_AMDXDNA=m. The touched file also compiles W=1 clean. Fixes: e252e3f3488a ("accel/amdxdna: Revise device bo creation and free") Cc: stable@vger.kernel.org # 6.18.x Assisted-by: LLM Signed-off-by: Eva Crystal <0xiviel@gmail.com> Signed-off-by: Sasha Levin commit d7b9770a487e149b11c58315a9fa108aa975c558 Author: Donald Hunter Date: Thu Nov 27 12:35:02 2025 +0000 ynl: fix schema check errors [ Upstream commit 1adc241f3940c172c8c674a62004d3c34b360ab3 ] Fix two schema check errors that have lurked since the attribute name validation was made more strict: not ok 2 conntrack.yaml schema validation 'labels mask' does not match '^[0-9a-z-]+$' not ok 13 nftables.yaml schema validation 'set id' does not match '^[0-9a-z-]+$' Signed-off-by: Donald Hunter Link: https://patch.msgid.link/20251127123502.89142-5-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a49853272bd3ddf862a5f5f5a3babba25099158 Author: Remy D. Farley Date: Tue Mar 3 19:57:41 2026 +0000 doc/netlink: netlink-raw: Add max check [ Upstream commit bf5a54bc0e3d8962474fcd611f1266eba036232f ] 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: Sasha Levin commit 56760e83aa4e8fd4aa6e6b739749ad09b9710cca Author: Paulo Alcantara Date: Sat Sep 26 19:20:30 2026 -0300 netfs: zero the tail of a short DIO/unbuffered read [ Upstream commit dd05add7b2b6004c5fa3a1f276f56d8668f86b65 ] The buffered read collector zero-fills the tail of a short read that stops below the inode's i_size (netfs_clear_unread()), so a read that races an extending write still returns the expected number of bytes. The non-buffered collector path does no such thing: it just records how much was transferred. Add the same zero-fill for the non-buffered case, gated on NETFS_SREQ_CLEAR_TAIL: a subreq's source sets that flag when a short result from it is known to be safe to treat as a hole, as opposed to NETFS_SREQ_HIT_EOF, which means the read genuinely ran off the end of the file and should be reported short as-is. Only CLEAR_TAIL should zero-fill here; a real EOF must stay a real short read. No source currently sets CLEAR_TAIL on an unbuffered/DIO subrequest, so this is inert on its own -- a following change teaches cifs to set it in the one case that needs it. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") 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. ] Signed-off-by: Sasha Levin commit 61519a5a1d70f4c0a04881b7ad672ccf932a2322 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 b5aa7f1773f8080062d3e435cd96ccf990edd1f8 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 867119b4b588037724b85839d534465f0334d9bd 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 639522e5056cade578a324acfa993ec6c9f7f5dc 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 50cff3f112d64db6e5f57355f79bc837db8fe132 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 fbd977e513971ccb4f0762a7f59eac500e474f89 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